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APPEAL BRIEF 

Sir: 

The Appellants submit this Appeal Brief in support of the Notice of Appeal filed on July 
21, 2006. A two-month extension of time is included. This Appeal is taken from the Advisory 
Action dated July 10, 2006 and the Final Rejection dated March 21, 2006, which are attached as 
Appendix B and Appendix C. 

I. REAL PARTY IN INTEREST 

The real party in interest for the above-identified patent application on appeal is Siemens 
Aktiengesellschaft by virtue of an Assignment recorded at the United States Patent and 
Trademark Office on March 25, 2002, at reel 012751, frame 0067. 



Application No.: 10/006,314 



II. RELATED APPEALS AND INTERFERENCES 

Appellants, Appellant's legal representative and the Assignee of the above-identified 
patent application do not know of any prior or pending appeals, interferences or judicial 
proceedings which may be related to, directly affect or be directly affected by or have a bearing 
on the Board's decision with respect to the above-identified Appeal. 
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III. STATUS OF CLAIMS 

Claims 1-12 are pending in the above-identified patent application, with claims 1,11 and 
12 being the only independent claims. As indicated in the Advisory Action, the previous §101 
rejection to claim 12 has been withdrawn. However, claims 1-12 stand rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over Non-Patent Literature entitled "A Language for User Control 
of Internet Telephony Services," to Lennox et al. in view of U.S. Patent No. 6,476,833 to 
Moshfeghi. Accordingly, claims 1-12 are being appealed in this Brief. A copy of the appealed 
claims is attached as Appendix A. 
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IV. STATUS OF AMENDMENTS 

Independent claims 1,11 and 12 were amended in the Response to the final Office Action 
dated March 21, 2006. In the Advisory Action dated July 10, 2006, the Examiner indicated that 
the amendments made to overcome the §101 rejections were entered, but the amendments made 
to overcome the §103 rejections were not. In particular, the Examiner indicated that the claim 
amendments proposed for overcoming the §103 rejections raised new issues requiring further 
search and consideration. No other substantive amendments were made in the application after 
the final rejection. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention as recited in independent claims 1, 11 and 12 is directed to a 
system, method and computer program for using a data processing system as a function of 
authorization in Internet Telephony. 

In pertinent part, a priority authorization level is defined which permits the execution of 
instructions with wider ranging access rights in comparison with instructions for more basic 
authorization levels. This defining of a priority authorization level is implemented for at least 
one priority user of the data processing system. After defining the priority authorization level of 
a user, the authorization level can be used to define the instructions which a user can execute. 

An important aspect of the invention is the defining of different authorization levels for 
users of the data processing system (i.e., priority authorization versus basic authorization), which 
includes different ranges in access rights. 

Although specification citations are given in accordance with C.F.R. 1.192(c), these 
reference numerals and citations are merely examples of where support may be found in the 
specification for the terms used in this section of the Brief. There is no intention to suggest in 
any way that the terms of the claims are limited to the examples in the specification. Pointing 
out specification support for the claim terminology as is done here to comply with rule 1.192(c) 
does not in any way limit the scope of the claims to those examples from which they find 
support. Nor does this exercise provide a mechanism for circumventing the law precluding 
reading limitations into the claims from the specification. In short, the references numerals and 
specification citations are not to be construed as claim limitations or in any way used to limit the 
scope of the claims. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-12 stand rejected under 35 U.S.C. §103(a) as being unpatentable over Non- 
Patent Literature entitled "A language for User Control of Internet Telephony Services," to 
Lennox et al in view of U.S. Patent No. 6,476,833 to Moshfeghi. 
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VII. ARGUMENT 

A. LEGAL STANDARDS 

In making a determination that an invention is obvious, the Patent Office has the initial 
burden of establishing a prima facie case of obviousness. In re Rijckaert, 9 F.3d 1531, 1532, 28 
U.S. P.Q.2d 1955, 1956 (Fed. Cir. 1993). "If the examination at the initial stage does not produce 
a prima facie case of unpatentability, then without more the applicant is entitled to grant of the 
patent." In re Oetiker, 24 U.S.P.Q.2d 1443, 1444 (Fed. Cir. 1992). 

In order to maintain a prima facie case of obviousness under 35 U.S.C. §103, the 
Examiner must satisfy the following criteria: 1) a suggestion or motivation, either in the cited 
references themselves or in the knowledge generally available to one of ordinary skill in the art, 
to modify the references or combine their teachings to arrive at the invention; 2) a reasonable 
expectation of success at arriving at the invention, if the combination of the cited references is 
made; and 3) a teaching of suggestion of all the recited claim limitations in the combination of 
the cited references, (see MPEP 2142). 

The teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art, and not based on applicant's 
disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). The initial burden is 
on the examiner to provide some suggestion of the desirability of doing what the inventor has 
done. "To support the conclusion that the claimed invention is directed to obvious subject 
matter, either the references must expressly or impliedly suggest the claimed invention or the 
examiner must present a convincing line of reasoning as to why the artisan would have found the 
claimed invention to have been obvious in light of the teachings of the references." Ex parte 
Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985). When the motivation to combine the 
teachings of the references is not immediately apparent, it is the duty of the examiner to explain 
why the combination of the teachings is proper. Ex parte Skinner, 2 USPQ2d 1788 (Bd. Pat. 
App. & Inter. 1986). (see MPEP 2142). 

Further, the Federal Circuit has held that it is "impermissible to use the claimed invention 
as an instruction manual or 'template' to piece together the teachings of the prior art so that the 
claimed invention is rendered obvious." In re Fritch, 23 U.S.P.Q.2d 1780, 1784 (Fed. Cir. 
1992). "One cannot use hindsight reconstruction to pick and choose among isolated disclosures 
in the prior art to deprecate the claimed invention" In re Fine, 837 F.2d 1071 (Fed. Cir. 1988). 
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Moreover, the Federal Circuit has held that "obvious to try" is not the proper standard 
under 35 U.S.C. §103. Ex parte Goldgaber, 41 U.S.P.Q.2d 1172, 1177 (Fed. Cir. 1996). "An- 
obvious-to-try situation exists when a general disclosure may pique the scientist curiosity, such 
that further investigation might be done as a result of the disclosure, but the disclosure itself does 
not contain a sufficient teaching of how to obtain the desired result, or that the claim result would 
be obtained if certain directions were pursued." In re Eli Lilly and Co., 14 U.S.P.Q.2d 1741, 
1743 (Fed. Cir. 1990). 
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B. THE REJECTION UNDER 35 U.S.C. $1 03(A) IS IMPROPER BECAUSE 
LENNOX ET AL. IN VIEW OF MOSHFEGHI DOES NOT RENDER OBVIOUS THE 
CLAIMED INVENTION 

Claims 1-12 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Lennox 
et al. ("A Language for User Control of Internet Telephony Services) in view of Moshfeghi (US 
Patent 6,467,833). 

The cited art, alone or in combination, fails to teach or suggest the feature of "defining a 
priority authorization level, which permits execution of instructions with wider ranging access 
rights in comparison to the instructions of the basic authorization level, for at least one priority 
user of the data processing system" as recited in claim 1 and similarly recited in claims 1 1 and 
12. 

Regarding Lennox, the disclosure teaches various CPL script arrangements for call 
processing (see sections 2.1-2.3, pages 2-4). In the passages cited by the Office Action (sections 
6.1-7.2, pages 20-27), the disclosure discusses a CPL location model (see also section 2.3, page 
4), where signaling operations are dependent upon location sets, where location nodes may be 
added or removed. Under the disclosure, users may be authorized to access specific nodes, 
depending on whether or not they are in a specified location (section 6.1). Furthermore, 
authorization is conducted during connection to protect users against denial of service attacks 
(FIGS. 28 and 29; section 14). 

However, nowhere in the disclosure of Lennox is it disclosed that a priority authorization 
level is used to permit execution of instructions with wider ranging access rights. In fact, the 
proxy mode of page 25 has nothing to do with authorization. Instead, page 25 merely describes 
prioritizing a list of alternate locations to which a call may be forwarded. Additionally, Lennox 
at pages 40 and 43 merely describe a call set-up, and the code illustrated in FIG. 29 merely 
authenticates a user's SIP to a voicemail command. Finally, Lennox states that "a method by 
which scripts are transmitted from a client to a server must be strongly authenticated." However, 
"[s]uch a method is not specified in this document." (see, page 42). Thus, none of the cited 
sections of Lennox relate to prioritized authorization of access rights, as claimed. 

Furthermore, Moshfeghi does not solve the deficiencies of Lennox, discussed above. The 
broadly cited passage of col. 2, line 55 - col. 4, line 32 teaches the use of embedded browser 
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functions to prevent unauthorized linking (col. 3, lines 8-13; 26-30). Notwithstanding the fact 
that there is absolutely no teaching, suggesting or motivation to combine this teaching with 
Lennox, Moshfeghi also fails to teach prioritized authorization. 

In light of the above, the Applicants respectfully submit that Examiner has not satisfied 
the criteria necessary for maintaining a prima facie case of obviousness and independent claims 
1,11 and 12 are patentable over the cited prior art. 
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VIII. CONCLUSION 



The Appellants respectfully submit that claims 1-12 are non-obvious in view of the cited 
art. Accordingly, the Appellants respectfully submit that the rejections of pending claims 1-12 
are erroneous in law and fact and should be reversed by this Board. 



Respectfully submitted, 
BELL, BOYD & LLOYD LLC 



Peter Zura 
Reg. No. 48,196 
Customer No.: 29177 
Phone: (312) 807-4208 



Dated: November 21. 2006 
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APPENDIX A 



PENDING CLAIMS ON APPEAL OF 
U.S. PATENT APPLICATION SERIAL NO. 10/006,314 



Listing of Claims: 

Claim 1. (previously presented) A method for using a data processing system as a 
function of an authorization in Internet Telephony, the method comprising the steps of: 

defining a basic authorization level relating to execution of specific instructions 
using the data processing system for at least one basic user of the data processing system; 

defining a priority authorization level, which permits execution of instructions 
with wider ranging access rights in comparison to the instructions of the basic authorization 
level, for at least one priority user of the data processing system; 

noting at least one of the instructions and a syntax of the instructions for the basic 
authorization level in a basic file section; 

noting at least one of the instructions and a syntax of the instructions for the 
priority authorization level in a priority file section; 

determining the authorization level of a user before the execution of the 
instructions of the user; and 

using one of the basic file section and the priority file section, as a function of the 
authorization levels determined, to define the instructions which the user can execute. 



Claim 2. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 1, the method further comprising the steps of: 
storing the basic file section in a basic file; and 
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storing the preferred file section in a priority file, which differs from the basic file. 

Claim 3. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 1, wherein at least one of the basic file section and the priority 
file section does not itself define a program or program section which can be executed by a 
processor. 

Claim 4. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 1, the method further comprising the step of: 

defining the instructions of the basic authorization level and at least one of an 
additional instruction and an expanded syntax in comparison with the syntax of the basic 
authorization level for the priority authorization level. 

Claim 5. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 1, the method further comprising the steps of: 

transmitting, by a user, an instruction file with instructions to the data processing 
system for determining the authorization level; 

checking the instructions contained in the instruction file as a function of the 
authorization level using one of the basic file section and the priority file section; and 

storing the instruction file for a later execution if it contains only instructions 
which are valid for the authorization level which is determined. 
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Claim 6. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 5, the method further comprising the steps of: 

determining the authorization level of the user before the processing of the 
instruction file; and 

using one of the basic file section and the priority file section to process the 
instruction file as a function of the authorization level for the processing of the instruction file. 

Claim 7. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 5, wherein the basic file section and the priority file section 
contain at least one of instructions and a syntax of the instructions of a markup language, which 
is used to described contents of character chains, the markup language being selected from the 
group consisting of SGML, XML, HTML 4.0, and a markup language based on one of these 
languages, such that the instruction file contains instructions in the markup language. 

Claim 8. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 5, wherein the basic file section in the priority file section 
define at least one of instructions and a syntax of the instructions for controlling a voice 
transmission via at least one of a circuit-switched telephone network and a packet-switched data 
transmission network, the syntax of instructions of a language selected from a group consisting 
of CPL and a language based on CPL, such that the instruction filed defines instructions for 
controlling the voice transmission. 
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Claim 9. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 5, wherein, for processing the instruction file, a same parser 
program is used for decomposing the instruction file into individual instructions. 

Claim 10. (original) A method for using a data processing system as a function of an 
authorization as claimed in claim 5, wherein a same application program is used for executing 
the instructions, irrespective of the authorization level. 

Claim 1 1 . (previously presented) A data processing system which is used as a 
function of an authorization in Internet Telephony, comprising: 

a part for defining a basic authorization level relating to execution of specific 
instructions using the data processing system for at least one basic user of the data processing 
system; 

a part for defining a priority authorization level, which permits execution of 
instructions with wider ranging access rights in comparison to the instructions of the basic 
authorization level, for at least one priority user of the data processing system; 

a part for noting at least one of the instructions and a syntax of the instructions for 
the basic authorization level in a basic file section; 

a part for noting at least one of the instructions and a syntax of the instructions for 
the priority authorization level in a priority file section; 

a part for determining the authorization level of a user before the execution of the 
instructions of the user; and 



iv 



Application No.: 10/006,314 

a part for using one of the basic file section and the priority file section, as a 
function of the authorization level determined, to define the instructions which the user can 
execute. 

Claim 12. (previously presented) A program having executable code stored on a 
computer-readable medium that when executed by one or more processors performs a method 
for using a data processing system as a function of an authorization in Internet Telephony, the 
method comprising: 

defining a basic authorization level relating to execution of specific instructions 
using the data processing system for at least one basic user of the data processing system; 

defining a priority authorization level, which permits execution of instructions 
with wider ranging access rights in comparison to the instructions of the basic authorization 
level, for at least one priority user of the data processing system; 

noting at least one of the instructions and a syntax of the instructions for the basic 
authorization level in a basic file section; 

noting at least one of the instructions and a syntax of the instructions for the 
priority authorization level in a priority file section; 

determining the authorization level of a user before the execution of the 
instructions of the user; and 

using one of the basic file section and the priority file section, as a function of the 
authorization levels determined, to define the instructions which the user can execute. 
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Advisory Action 
Before the Filing of an Appeal Brief 



Examiner 
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BENINI, GIOVANNI 
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-The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
THE REPLY FILED 20 June 2006 FAILS TO PLACE THIS APPLICATION IN CONDITION FOR ALLOWANCE. 

1. M The reply was filed after a final rejection, but prior to or on the same day as filing a Notice of Appeal. To avoid abandonment of 

this application, applicant must timely file one of the following replies: (1) an amendment, affidavit, or other evidence, which 
places the application in condition for allowance; (2) a Notice of Appeal (with appeal fee) in compliance with 37 CFR 41.31; or 
(3) a Request for Continued Examination (RCE) in compliance with 37 CFR 1.114. The reply must be filed within one of the 
following time periods: 

a) H The period for reply expires 3months from the mailing date of the final rejection. 

b) □ The period for reply expires on: (1 ) the mailing date of this Advisory Action, or (2) the date set forth in the final rejection, whichever is later. In no 

event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of the final rejection. 

Examiner Note: If box 1 is checked, check either box (a) or (b). ONLY CHECK BOX (b) WHEN THE FIRST REPLY WAS FILED WITHIN TWO 

MONTHS OF THE FINAL REJECTION. See MPEP 706.07(0. 
Extensions of time may be obtained under 37 CFR 1 .136(a). The date on which the petition under 37 CFR 1 .136(a) and the appropriate extension fee have 
been filed is the date for purposes of determining the period of extension and the corresponding amount of the fee. The appropriate extension fee under 37 
CFR 1 .17(a) is calculated from: (1) the expiration date of the shortened statutory period for reply originally set in the final Office action; or (2) as set forth in (b) 
above, if checked. Any reply received by the Office later than three months after the mailing date of the final rejection, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 
NOTICE OF APPEAL 

2. DThe Notice of Appeal was filed on . A brief in compliance with 37 CFR 41.37 must be filed within two months of the date 

of filing the Notice of Appeal (37 CFR 41 .37(a)), or any extension thereof (37 CFR 41 .37(e)), to avoid dismissal of the appeal. 
Since a Notice of Appeal has been filed, any reply must be filed within the time period set forth in 37 CFR 41 .37(a). 
AMENDMENTS 

3. S The proposed amendment(s) filed after a final rejection, but prior to the date of filing a brief, will not be entered because 

(a) |3 They raise new issues that would require further consideration and/or search (see NOTE below); 

(b) E3 They raise the issue of new matter (see NOTE below); 

(c) D They are not deemed to place the application in better form for appeal by materially reducing or simplifying the issues for 

appeal; and/or 

(d) D They present additional claims without canceling a corresponding number of finally rejected claims. 

NOTE: See Continuation Sheet . (See 37 CFR 1.116 and 41.33(a)). 

4. □ The amendments are not in compliance with 37 CFR 1.121. See attached Notice of Non-Compliant Amendment (PTOL-324). 

5. (3 Applicant's reply has overcome the following rejection(s): 101 rejection of claim 12 . 

6. □ Newly proposed or amended claim(s) would be allowable if submitted in a separate, timely filed amendment canceling 

the non-allowable claim(s). 

7. ^ For purposes of appeal, the proposed amendment(s): a) □ will not be entered, or b) □ will be entered and an explanation of 

how the new or amended claims would be rejected is provided below or appended. 
The status of the claim(s) is (or will be) as follows: 

Claim(s) allowed: . 

Claim(s) objected to: . 

Claim(s) rejected: 1-12 . 

Claim(s) withdrawn from consideration: . 

AFFIDAVIT OR OTHER EVIDENCE 

8. □ The affidavit or other evidence filed after a final action, but before or on the date of filing a Notice of Appeal will not be entered 

because applicant failed to provide a showing of good and sufficient reasons why the affidavit or other evidence is necessary 
and was not earlier presented. See 37 CFR 1.116(e). 

9. □ The affidavit or other evidence filed after the date of filing a Notice of Appeal, but prior to the date of filing a brief, will not be 

entered because the affidavit or other evidence failed to overcome all rejections under appeal and/or appellant fails to provide a 
showing a good and sufficient reasons why it is necessary and was not earlier presented. See 37 CFR 41.33(d)(1). 

10. □ The affidavit or other evidence is entered. An explanation of the status of the claims after entry is below or attached. 
REQUEST FOR RECONSIDERATION/OTHER 

1 1. □ The request for reconsideration has been considered but does NOT place the application in condition for allowance because: 

12. □ Note the attached Information Disclosure Statement(s). (PTO/SB/08 or PTO-1449) Paper No(s). 

13. □ Other . 
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Continuation of 3. NOTE: Applicant has amended the independent claims to recite that "the specific instructions are received in an 
Internet Markup Language and parsed user a parser . Applicant mentioned page 5, lines 5-15 for support. However, the citation 
provided by Applicant does not refer to parser nor the claimed limitation as amended. The proposed amendment will not be entered 
because they raise the issue of new matter and therefore, they require at least further consideration. It is noted that the use of Markup 
Language was already cited in the dependent claims and disclosed by the reference as explained in the Office action. 
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- The MAILING DATE of this communication appears on the cover sheet with the correspondence address » 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

• Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1)^ Responsive to communication® filed on 12/27/2005 . 
2a)^ This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) ^ Claim(s) M2 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) G3 Claim(s) ±12 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) S The specification is objected to by the Examiner. 

10) ^ The drawing(s) filed on 04 December 2001 is/are: a)KI accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

11) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. §119 

12) ^ Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 
a)M All b)Q Some * c)D None of: 

1 .M Certified copies of the priority documents have been received. 

2. D Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attachment(s) 

1 ) 13 Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-41 3) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . 

3) □ Information Disclosure Statement(s) (PTO-1 449 or PTO/SB/08) 5) □ Notice of Informal Patent Application (PTO-1 52) 

Paper No(s)/Mail Date . 6) □ Other: . 
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DETAILED ACTION 

Response to Arguments 
1 . In response to communications filed on 12/27/2005, applicant amends claim 12. The 
following claims 1-12 are presented for examination. 

1.1 In response to communications filed on 12/27/2005, Applicant has amended the 
specification to overcome the objection from the last Office Action. However, the amendment 
does not reflect any changes. 

Applicant's remarks, pages 8-9, filed on 12/27/2005, with respect to the rejection of 
claims 1-12 have been fully considered but they are not persuasive. Applicant argues that the 
reference does not teach a priority level with wider ranging access rights. Examiner respectfully 
disagrees. Lenox does disclose defining CPL extensions (priority authorization level with wider 
ranging access rights) to the basic or default behavior (basic authorization level), page 25 states 
"CPL extensions to allow in-call or end-of-call operations will require an additional output, such 
as success to be added". . . users may specify that the one with highest priority be tried first (see 
example on page 25). Also, in another embodiment as specified in the office action, page 40 
provides an example where a priority authorization level is defined by the user which permits 
call from his boss to be directed to his mobile phone and all other calls to be directed to 
voicemail. Several examples of CPL extensions that define priority authorization level are 
disclosed throughout the disclosure. For at least the reasons cited above and in the Office Action 
applicant has not overcome the prior art and claims 1-12 remain rejected. 
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Specification 

2. The disclosure is objected to because it contains embedded hyperlinks and/or other form 
of browser-executable codes (see page 2, line 3; page 10, line 5). Applicant is required to delete 
the embedded hyperlinks and/or other form of browser-executable codes. Applicant is suggested 
to enclose the hyperlinks in quotation marks, remove the "http://www" or appropriate correction 
to make them non-executable. SeeMPEP§ 608.01. 

Claim Rejections - 35 USC§101 

3. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

Claim 12 is rejected under 35 U.S.C. 101 because the claimed invention is directed to 
non-statutory subject matter. The program recited in claim 12 without a computer-readable 
medium needed to realize the computer program's functionality is non-statutory functional 
descriptive material. Claim 12 reciting "The program having a command sequence . . . 
comprising"; the claim is directed to a program per se and is not embodied in a computer 
readable medium, in addition it is not executed by a machine. It appears that the preamble 
recites a processor executing a method and the claim is claiming a program per se. See MPEP § 
2106. IV.B.l(b). 

See also "http://www.uspto.gov/web/offices/dcom/bpai/prec/2003-2088.pdf. 

Appeal No. 2003-2088 Application 08/093,516 

claim 6 is not in one of the categories of § 101); In re 

Bonczyk,10 Fed. Appx. 908 (Fed. Cir. 2001) (non- 
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precedential) ("fabricated energy structure" does not correspond 
to any statutory category of subject matter) . Music, art, and 
literature, if claimed as such, do not fit into any of the 
statutory categories because they are not physical things or 
acts. Another example seen in the USPTO is a claim to a computer 
program per se, i.e., a claim reciting solely a program 
comprising a set of computer instructions for performing certain 
functions, instead of a series of steps performed on a computer. 
The instructions are not physical things which would qualify as 
a machine, manufacture, or composition of matter, and the claim 
is not recited as a series of steps as a process. Thus, a 
computer program per se is not statutory subject matter because 
it does not fall within any statutory class. See In re 
Chatfield,545 F.2d 152, 159, 191 USPQ 730, 737 (CCPA 1976) 
(Rich, J. , dissenting) ("It has never been otherwise than 
perfectly clear to those desiring patent protection on 
inventions which are new and useful programs for general purpose 
computers (software) that the only way it could be obtained 
would be to describe and claim(35 U.S.C. § 112) the invention as 
a 'process' or a 'machine. '"); In re Lowry, 32 F.3d 1579, 32 
USPQ2d 1031 (Fed. Cir. 1994) (memory containing a stored data 
structure was statutory subject matter, which has been 
interpreted to mean that programs stored on a physical medium 
are statutory subject matter as a "manufacture") . 

A series of steps which is not tied to a particular machine 
or apparatus, and which does not transform physical subject 
matter to a different state or thing, does not meet the 
statutory 



Claim Rejections - 35 USC § 103 
4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject matter 
sought to be patented and the prior art are such that the subject matter as a whole would have 
been obvious at the time the invention was made to a person having ordinary skill in the art to 
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which said subject matter pertains. Patentability shall not be negatived by the manner in which 
the invention was made. 

4. 1 Claims 1-12 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over Non-Patent 
Literature "A Language for User Control of Internet Telephony Services", pages 1-60 to Lennox 
et al, in view of US Patent 6,476,833 to Moshfeghi. 

4.2 As per claims 1, 2, 6, 7, 1 1, and 12, Lennox et al substantially teaches a method for 
using a data processing system as a function of an authorization, the method comprising the 
steps of: defining a CPL for location authorization that specifies specific instructions in the markup 
language using the data processing system to be executed relating only to location (see sections 6.2- 
7.1, pages 20-24) that meets the recitation of defining a basic authorization level relating to 
execution of specific instructions using the data processing system for at least one basic user of the 
data processing system. In another embodiment, figure 29, page 41 shows a complex example of 
an authorization level of a user that can be extended with a wider range of access rights as shown in 
figure 28, page 40 in comparison to the instructions of figure 29, for at least one priority user of the 
data processing system that meets the recitation of defining a priority authorization level, which 
permits execution of instructions with wider ranging access rights in comparison to the instructions of 
the basic authorization level, for at least one priority user of the data processing system. Lennox et al 
further suggests on page 40 that the method by which scripts are transmitted from client to 
servers must be strongly authenticated and servers should allow server administrators to control 
the details of what CPL operations are performed that meets the recitation of determining the 
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authorization level of a user before the execution of the instructions of the user; and discloses each 
script defining the instructions which the user can execute (figures 26-28 and pages 25, 40, and 43) 
that meets the recitation of using one of the basic file section and the priority file section, as a 
function of the authorization levels determined, to define the instructions which the user can execute. 
Lennox et al also suggests determining the authorization level of the user before processing 
(pages 40 and- 43). Lennox et al discloses in figures 28 and 29, syntax and instructions for the 
basic and extended authorization level that meets the recitation of noting at least one of the 
instructions and a syntax of the instructions for the basic authorization level in a basic file section; 
noting at least one of the instructions and a syntax of the instructions for the priority authorization 
level in a priority file section; Lennox et al discloses that the files comprise scripts (file sections), 
it is apparent that the files or PCL are stored in the computer (pages 5-7). 

Moshfeghi in an analogous art teaches a method and apparatus for providing 
configurable markup language such as HTML and XML, that restrict users execution of 
instruction, the method disclosed storing user profile records, the profile records defining a 
authorization level relating to each user's execution of specific instructions using the data processing 
system for at least one basic user of the data processing system (see summary of invention, column 
2, line 55 through column 4, line 32). Therefore, it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to modify the teaching of Lennox et al to store 
the scripts into users profile records and use one of the basic file section and the priority file 
section, as a function of the authorization levels determined, to define the instructions which the user 
can execute as taught by Moshfeghi to provide an additional flash memory in the second 
encryption sub-module and a CMOS memory coupled with the dual-port memory via the first 
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bus of the dual-port memory containing the encryption keys as taught in IBM Technical 
Disclosure Bulletin. One skilled in the art would have been lead to make such a modification 
because it would provide an easy way to control and filter user instructions by being responsive 
to the content or function privileges in the user's profiles as suggested by Moshfeghi (column 3, 
line 20 through column 4, line 32). 

As per claim 3, Lennox et al discloses extended file or program section in figure 28 
that is not defined in figure 29 to be executed by a processor other examples can be found on 
pages 47 et seq. that meets the recitation of wherein at least one of the basic file section and the 
priority file section does not itself define a program or program section, which can be executed 
by a processor (see figures 28 and 29). 

As per claim 4, Lennox et al suggests defining the instructions of the basic authorization 
level and at least one of an additional instruction and an expanded syntax in comparison with the 
syntax of the basic authorization level for the priority authorization level (pages 5 1-52). 

As per claim 5, the combination of Lennox et a! and Moshfeghi discloses transmitting, 
by a user, an instruction file with instructions to the data processing system for determining the 
authorization level (Lennox et al, pages 25-27); checking the instructions contained in the 
instruction file as a function of the authorization level using one of the basic file section and the 
priority file section (Lennox et al, pages 25-27 and pages 38-48 that also disclose filtering by way 
of examples); and storing the instruction file for a later execution if it contains only instructions 
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which are valid for the authorization level which is determined (Moshfeghi, column 16, lines 20- 
40). Claim 5 is therefore rejected on the same rationale as the rejection of claims 1 and 2). 

As per claim 8, Lennox et al suggests using voice transmission as a media type for 
Internet telephony services (see for example, Applicant's disclosure abstract, lines 1-4). 

As per claims 9-10, the combination of Lennox et al and Moshfeghi discloses the 
limitation of wherein, for processing the instruction file, a same parser program is used for 
decomposing the instruction file into individual instructions and wherein a same application program 
is used for executing the instructions, irrespective of the authorization level (see Lennox et al, figures 
28 and 29). 

Conclusion 

5. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 . 1 36(a) will be calculated from the mailing date of the advisory action. In no event, 
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however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

5. 1 The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure as the art discloses the use of access level control using markup language and user 
access control relating to instructions that can be executed by a user. 
US Patents: 6,931,532 Davis etal; 6,3 1 7,742 Nagaratman et al ; 5,778,365 Nishiyama 



5.2 Any inquiry concerning this communication or earlier communications from the 

examiner should be directed to Carl Colin whose telephone number is 571-272-3862. The 

examiner can normally be reached on Monday through Thursday, 8:00-6:30 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 

supervisor, Ayaz Sheikh can be reached on 571-272-3795. The fax phone number for the 

organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov . Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



6,859,671 Brown. 



to- 

Carl Colin 
Patent Examiner 
March 17, 2006 
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CPL: A Language for User Control of Internet Telephony Services 

STATUS OF THIS MEMO 

This document is an Internet -Draft and is in full conformance with 
all provisions of Section 10 of RFC2026. 

Internet -Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that 
other groups may also distribute working documents as Internet - 
Drafts. 

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet -Drafts as reference 
material or to cite them other than as "work in progress". 

The list of current Internet -Drafts can be accessed at 
http : //www. ietf . org/ietf /lid -abstracts . txt 

To view the list- Internet -Draft Shadow Directories, see 
http : //www . ietf . org/shadow . html . 



The Call Processing Language (CPL) is a language that can be used to 
describe and control Internet telephony services. It is designed to 
be implementable on either network servers or user agent servers . It 
is meant to be simple, extensible, easily edited by graphical 
clients, and independent of operating system or signalling protocol. 
It is suitable for running on a server where users may not be allowed 
to execute arbitrary programs, as it has no variables, loops, or 
ability to run external programs. 

This document is a product of the IP Telephony (IPTEL) working group 
of the Internet Engineering Task Force. Comments are solicited and 
should be addressed to the working group's mailing list at 
iptel@lists.research.bell-labs.com and/or the authors. 
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1 Introduction 

The Call Processing Language (CPL) is a language that can be used to 
describe and control Internet telephony services. It is not tied to 
any particular signalling architecture or protocol; it is anticipated 
that it will be used with both SIP [1] and H.323 [2] . 

The CPL is powerful enough to describe a large number of services and 
features, but it is limited in power so that it can run safely in 
Internet telephony servers. The intention is to make it impossible 
for users to do anything more complex (and dangerous) than describing 
Internet telephony services. The language is not Turing-complete, and 
provides no way to write loops or recursion. 

The CPL is also designed to be easily created and edited by graphical 
tools. It is based on XML [3] , so parsing it is easy and many 
parsers for it are publicly available. The structure of the language 
maps closely to its behavior, so an editor can understand any valid 
script, even ones written by hand. The language is also designed so 
that a server can easily confirm scripts' validity at the time they 
are delivered to it, rather that discovering them while a call is 
being processed. 

Implementations of the CPL are expected to take place both in 
Internet telephony servers and in advanced clients; both can usefully 
process and direct users' calls. This document primarily addresses 
the usage in servers. A mechanism will be needed to transport scripts 
between clients and servers; this document does not describe such a 
mechanism, but related documents will. 

The framework and requirements for the CPL architecture are described 
in RFC 2824, "Call Processing Language Framework and Requirements" 



1.1 Conventions of This Document 

In this document, the key words "MUST" , "MUST NOT", "REQUIRED" , 
"SHALL", "SHALL NOT" , "SHOULD", "SHOULD. NOT", "RECOMMENDED" , "MAY" , 
and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and 
indicate requirement levels for compliant CPL implementations . 



[4] . 



Some paragraphs are indented, like this; they give 
motivations of design choices, or questions for future 
discussion in the development of the CPL, and are not 
essential to the specification of the language. 



2 Structure of CPL Scripts 
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2.1 High-level Structure 



A CPL script consists of two types of information: ancillary 
information about the script, and call processing actions. 
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A call processing action is a structured tree that describes the 
operations and decisions a telephony signalling server performs on a 
call set-up event. There are two types of call processing actions: 
top-level actions and subactions. Top-level actions are actions that 
are triggered by signalling events that arrive at the server. Two 
top-level action names are defined: incoming, the action performed 
when a call arrives whose destination is the owner of the script; and 
outgoing, the action performed when a call arrives whose originator 
is the owner of the script. Subactions are actions which can be 
called from other actions. The CPL forbids subactions from being 
called recursively: see Section 9. 

Ancillary information is information which is necessary for a server 
to correctly process a script, but which does not directly describe 
any operations or decisions. Currently, no ancillary information is 
defined, but the section is reserved for use by extensions. 

2.2 Abstract Structure of a Call Processing Action 

Abstractly, a call processing action is described by a collection of 
nodes, which describe operations that can be performed or decisions 
which can be made. A node may have several parameters, which specify 
the precise behavior of the node; they usually also have outputs, 
which depend on the result of the decision or action. 

For a graphical representation of a CPL action, see Figure 1. Nodes 
and outputs can be thought of informally as boxes and arrows; the CPL 
is designed so that actions can be conveniently edited graphically 
using this representation. Nodes are arranged in a tree, starting at 
a single root node; outputs of nodes are connected to additional 
nodes. When an action is run, the action or decision described by the 
action's top-level node is performed; based on the result of that 
node, the server follows one of the node's outputs, and the 
subsequent node it points to is performed; this process continues 
until a node with no specified outputs is reached. Because the graph 
is acyclic, this will occur after a bounded and predictable number of 
nodes are visited. 

If an output to a node does not point to another node, it indicates 
that the CPL server should perform a node- or protocol-specific 
action. Some nodes have specific default behavior associated with 
them; for others, the default behavior is implicit in the underlying 
signalling protocol, or can be configured by the administrator of the 



Lennox/Schulzrinne [Page 3] 

□ 

Internet Draft CPL November 14, 2000 



server. For further details on this, see Section 11. 



busy 

| Address -switch | | location | | proxy | \ 

Call >| field: origin j ->| url : sip:jones@ j >| timeout :| timeout | 
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subfield: host | / | example.com | | 10s | 1 

1/ | | | | failure | 

subdomain-of : | | | | 

example.com ] j 

| / 

otherwise | / 

|\| . Voicemail 
I \- 



location 

url : sip:jones@ 
voicemail . 
example . com 



| redirect | . 
>l I • 

I I • 



Figure 1: Sample CPL Action: Graphical Version 



2.3 Location Model 

For flexibility, one piece of information necessary for the function 
of a CPL is not given as node parameters : the set of locations to 
which a call is to be directed. Instead, this set of locations is 
stored as an implicit global variable throughout the execution of a 
processing action (and its subactions) . This allows locations to be 
retrieved from external sources, filtered, and so forth, without 
requiring general language support for such operations (which could 
harm the simplicity and tractability of understanding the language) . 
The specific operations which add, retrieve, or filter location sets 
are given in Section 6. 

For the incoming top-level call processing action, the location set 
is initialized to the empty set. For the outgoing action, it is 
initialized to the destination address of the call. 

2.4 XML Structure 
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Syntactically, CPL scripts are represented by XML documents. XML is 
thoroughly specified by [3] , and implementors of this specification 
should be familiar with that document, but as a brief overview, XML 
consists of a hierarchical structure of tags; each tag can have a 
number of attributes. It is visually and structurally very similar to 
HTML [6] , as both languages are simplifications of the earlier and 
larger standard SGML [7] . 

See Figure 2 for the XML document corresponding to the graphical 
representation of the CPL script in Figure 1. Both nodes and outputs 
in the CPL are represented by XML tags; parameters are represented by 
XML tag attributes. Typically, node tags contain output tags, and 



http://tools.ietf.org/wg/iptel/draft-ietf-iptel-cpl/draft-ietf-iptel-cpl-04.txt 



9/14/05 



rage o 01 ou 



vice-versa (with a few exceptions: see Sections 6.1, 6.3, 8.1, and 
8.2) . 

The connection between the output of a node and another node is 
represented by enclosing the tag representing the pointed-to node 
inside the tag for the outer node's output. Convergence (several 
outputs pointing to a single node) is represented by subactions, 
discussed further in Section 9. 

The higher-level structure of a CPL script is represented by tags 
corresponding to each piece of ancillary information, subactions, and 
top-level actions, in order. This higher-level information is all 
enclosed in a special tag cpl, the outermost tag of the XML document. 

A complete Document Type Declaration for the CPL is provided in 
Appendix C. The remainder of the main sections of this document 
describe the semantics of the CPL, while giving its syntax 
informally. For the formal syntax, please see the appendix. 



3 Document Information 

This section gives information describing how CPL scripts are 
identified. 

3.1 CPL Document Identifiers for XML 

A CPL script list which appears as a top-level XML document is 
identified with the formal public identifier " -//IETF/ /DTD RFCxxxx 
CPL 1.0//EN" . 

A CPL embedded as a fragment within another XML document is 
identified with the XML namespace identifier "http://www.rfc- 
editor . org/rf c/rf cxxxx . txt " . 
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<?xml version="l . 0" ?> 

<!D0CTYPE cpl PUBLIC " -/ /IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 
<cpl> 

<subaction id="voicemail"> 

< location url= "sip : jonesOvoicemail . example . com" > 
<redirect /> 

</location> 
</subaction> 

<incoming> 

<address-switch field= "origin" subf ield="host"> 
oddress subdomain-of ="example. com"> 
< location url="sip : jones@example . com"> 
<proxy timeout="10"> 
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<busy> <sub ref ="voicemail " /> </busy> 
<noanswer> <sub ref ="voicemail" /> </noanswer> 
<failure> <sub ref ="voicemail" /> </failure> 
</proxy> 
</location> 
</address> 
<otherwise> 

<sub ref ="voicemail" /> 
</otherwise> 
</address-switch> 
</incoming> 
</cpl> 



Figure 2: Sample CPL Script: XML Version 



[Note to RFC editor: please replace "xxxx" above with the 
number of this RFC] 



Note that the URIs specifying XML namespaces are only 
globally unique names; they do not have to reference any 
particular actual object. The URI of a canonical source of 
this specification meets the requirement of being globally 
unique, and is also useful to document the format. 

3.2 MIME Registration 

As an XML type, CPL's MIME registration conforms with "XML Media 
Types, " RFC YYYY [8] . 
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[Note to RFC Editor: please replace "YYYY" in this section, 
and in bibliography entry [8] , with the RFC number assigned 
to the Internet -Draft draft-murata-xml-09.txt, approved for 
Proposed Standard.] 

MIME media type name: application 

MIME subtype name: cpl+xml 

Mandatory parameters : none 

Optional parameters : charset 

As for application/xml in RFC YYYY. 

Encoding considerations: As for application/xml in RFC YYYY. 

Security considerations: See Section 14, and Section 10 of RFC 
YYYY. 

Interoperability considerations: Different CPL servers may use 
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incompatible address types. However, all potential 
interoperability issues should be resolvable at the time a 
script is uploaded; there should be no interoperability 
issues which cannot be detected until runtime. 

Published specification: This document. 

Applications which use this media type: None publicly released 
at this time, as far as the authors are aware. 

Additional information: 

Magic number: None 

File extension: .cpl or .xml 

Macintosh file type code: "TEXT" 

Person and e-mail address for further information: 
Jonathan Lennox <lennox@cs .Columbia. edu> 
Henning Schulzrinne <hgs@cs. Columbia. edu> 

Intended usage: COMMON 

Author/Change Controller: The IETF. 

4 Script Structure: Overview 



Lennox/Schulzrinne . [Page 7] 

Internet Draft CPL November 14, 2000 



As mentioned, a CPL script consists of ancillary information, 
subactions, and top-level actions. The full syntax of the cpl node is 
given in Figure 3 . 



Tag : cpl 
Parameters : None 

Sub-tags: ancillary See Section 10 
subaction See Section 9 

outgoing Top-level actions to take on this user's 

outgoing calls 
incoming Top-level actions to take on this user's 

incoming calls 



Figure 3: Syntax of the top-level cpl tag 



Call processing actions, both top-level actions and sub-actions, 
consist of a tree of nodes and outputs. Nodes and outputs are both 
described by XML tags . There are four categories of CPL nodes : 
switches , which represent choices a CPL script can make; location 
modifiers , which add or remove locations from the location set; 
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signalling operations , which cause signalling events in the 
underlying protocol; and non-signalling operations , which trigger 
behavior which does not effect the underlying protocol. 

5 Switches 

Switches represent choices a CPL script can make, based on either 
attributes of the original call request or items independent of the 
call. 

All switches are arranged as a list of conditions that can match a 
variable. Each condition corresponds to a node output; the output 
points to the next node to execute if the condition was true. The 
conditions are tried in the order they are presented in the script; 
the output corresponding to the first node to match is taken. 

There are two special switch outputs that apply to every switch type. 
The output not-present, which MAY occur anywhere in the list of 
outputs, is true if the variable the switch was to match was not 
present in the original call setup request. (In this document, this 
is sometimes described by saying that the information is "absent".) 
The output otherwise, which MUST be the last output specified if it 
is present, matches if no other condition matched. 
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If no condition matches and no otherwise output was present in the 
script, the default script behavior is taken. See Section 11 for more 
information on this. 

5.1 Address Switches 

Address switches allow a CPL script to make decisions based on one of 
the addresses present in the original call request. They are 
summarized in Figure 4 . 



Node: 
Outputs: 
Parameters : 



Output : 
Parameters : 



address -switch 
address 
field 
subf ield 



contains 
subdomain-of 



Specific addresses to match 

origin, destination, or original -destination 
address-type, user, host, port, tel, or display 
(also: password and alias- type) 



exact match 

substring match (for display only) 
sub-domain match (for host, tel only) 



Figure 4: Syntax of the address -switch node 



Address switches have two node parameters: field, and subf ield. The 
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mandatory field parameter allows the script to specify which address 
is to be considered for the switch: either the call's origin address 
(field "origin"), its current destination address (field 
"destination"), or its original destination (field "original - 
destination"), the destination the call had before any earlier 
forwarding was invoked. Servers MAY define additional field values. 

The optional subfield specifies what part of the address is to be 
considered. The possible subfield values are: address-type, user, 
host, port, tel, and display. Additional subfield values MAY be 
defined for protocol -specif ic values. (The subfield password is 
defined for SIP in Section 5.1.1; the subfield alias-type is defined 
for H.323 in Appendix B.l.) If no subfield is specified, the 
"entire" address is matched; the precise meaning of this is defined 
for each underlying signalling protocol. Servers MAY define 
additional subfield values. 

The subfields are defined as follows: 

address -type This indicates the type of the underlying address; 
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i.e., the URI scheme, if the address can be represented by 
a URI. The types specifically discussed by this document 
are sip, tel, and h323. The address type is not case- 
sensitive. It has a value for all defined address types. 

user This subfield of the address indicates, for e-mail style 
addresses, the user part of the address. For telephone 
number style address, it includes the subscriber number. 
This subfield is case-sensitive; it may be absent. 

host This subfield of the address indicates the Internet host 
name or IP address corresponding to the address, in host 
name, IPv4 , or IPv6 format. For host names only, subdomain 
matching is supported with the subdomain-of match operator. 
It is not case sensitive, and may be absent. 

port This subfield indicates the TCP or UDP port number of the 
address, numerically in decimal format. It is not case 
sensitive, as it MUST only contain decimal digits. It may 
be absent; however, for address types with default ports, 
an absent port matches the default port number. 

tel This subfield indicates a telephone subscriber number, if 
the address contains such a number. It is not case 
sensitive (the telephone numbers may contain the symbols 
"A 1 "*B 1 ~C and ~D'), and may be absent. It may be matched 
using the subdomain-of match operator. Punctuation and 
separator characters in telephone numbers are discarded. 

display This subfield indicates a "display name" or user-visible 
name corresponding to an address. It is a Unicode string, 
and is matched using the case-insensitive algorithm 
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described in Section 5.2. The contains operator may be 
applied to it. It may be absent. 

For any completely unknown subfield, the server MAY reject the script 
at the time it is submitted with an indication of the problem; if a 
script with an unknown subfield is executed, the server MUST consider 
the not-present output to be the valid one. 

The address output tag may take exactly one of three possible 
parameters, indicating the kind of matching allowed. 

is An output with this match operator is followed if the 
subfield being matched in the address -switch exactly 
matches the argument of the operator. It may be used for 
any subfield, or for the entire address if no subfield was 
specified. 
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subdomain-of This match operator applies only for the subfields 
host and tel. In the former case, it matches if the 
hostname being matched is a subdomain of the domain given 
in the argument of the match operator; thus, subdomain- 
of = "example . com" would match the hostnames "example.com", 
"research.example.com", and 

"zaphod.sales.internal.example.com". IP addresses may be 
given as arguments to this operator; however, they only 
match exactly. In the case of the tel subfield, the output 
matches if the telephone number being matched has a prefix 
that matches the argument of the match operator; 
subdomain-of ="1212555" would match the telephone number "1 
212 555 1212." 

contains This match operator applies only for the subfield 
display. The output matches if the display name being 
matched contains the argument of the match as a substring. 

5.1.1 Usage of address -switch with SIP 

For SIP, the origin address corresponds to the address in the From 
header; destination corresponds to the Request-URI; and original- 
destination corresponds to the To header. 

The display subfield of an address is the display-name part of the 
address, if it is present. Because of SIP's syntax, the destination 
address field will never have a display subfield. 

The address-type subfield of an address is the URI scheme of that 
address. Other address fields depend on that address-type. 

For sip URLs, the user, host, and port subfields correspond to the 
"user," "host," and "port" elements of the URI syntax. The tel 
subfield is defined to be the "user" part of the URI, with visual 
separators stripped, 
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if and only if the "user=phone" parameter is given to the URI. An 
additional subfield, password is defined to correspond to the 
"password" element of the SIP URI, and is case-sensitive. However, 
use of this field is NOT RECOMMENDED for general security reasons. 

For tel URLs, the tel and user subfields are the subscriber name; in 
the former case, visual separators are stripped. The host and port 
subfields are both not present. 

For h323 URLs, subfields MAY be set according to the scheme described 
in Appendix B. 
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For other URI schemes, only the address-type subfield is defined by 
this specification; servers MAY set other pre-defined subfields, or 
MAY support additional subfields. 

If no subfield is specified for addresses in SIP messages, the string 
matched is the URI part of the address. For "sip" URLs, all 
parameters are stripped; for other URLs, the URL is used verbatim. 

5.2 String Switches 

String switches allow a CPL script to make decisions based on free- 
form strings present in a call request. They are summarized in Figure 
5. 



Node : 
Outputs : 
Parameters : 



Output : 
Parameters : 



string -switch 

string 

field 



string 



Specific string to match 

subject, organization, user -agent, 

language, or display 



exact match 
substring match 



Figure 5: Syntax of the string-switch node 



String switches have one node parameter: field. The mandatory field 
parameter specifies which string is to be matched. 

String switches are dependent on the call signalling protocol being 
used. 

Five fields are defined, listed below. The value of each of these 
fields, except as specified, is a free -form Unicode string with no 
other structure defined. 

subject The subject of the call. 
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organization The organization of the originator of the call. 

user-agent The name of the program or device with which the call 
request was made. 

language The languages in which the originator of the call 

wishes to receive responses. This contains a list of RFC 
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1766 [9] language tags, separated by commas. 



Note that matching based on contains is likely to be 
much more useful than matching based on is, for this 
field. 

display Free-form text associated with the call, intended to be 
displayed to the recipient, with no other semantics defined 
by the signalling protocol . 

Strings are matched as case-insensitive Unicode strings, in the 
following manner. First, strings are canonicalized to the 
"Compatibility Composition" (KC) form, as specified in Unicode 
Technical Report 15 [10] . Then, strings are compared using locale- 
insensitive caseless mapping, as specified in Unicode Technical 
Report 21 [11] . 



Code to perform the first step, in Java and Perl, is 
available; see the links from Annex E of UTR 15 [10] . The 
case-insensitive string comparison in the Java standard 
class libraries already performs the second step; other 
Unicode-aware libraries should be similar. 

The output tags of string matching are named string, and have a 
mandatory argument, one of is or contains, indicating whole -string 
match or substring match, respectively. 

5.2.1 Usage of string- switch with SIP 

For SIP, the fields subject, organization, and user-agent correspond 
to the SIP header fields with the same name. These are used verbatim 
as they appear in the message. 

The field language corresponds to the SIP Accept -Language header. It 
is converted to a list of comma - separated languages as described 
above . 

The field display is not used, and is never present. 
5 . 3 Time Switches 

Time switches allow a CPL script to make decisions based on the time 
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and/or date the script is being executed. They are summarized in 
Figure 6. 

Time switches are independent of the underlying signalling protocol. 
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Node : 
Outputs : 
Parameters : 



Output : 
Parameters : 



time-switch 
time 
tzid 
tzurl 

time 

dtstart 

dtend 

duration 

freq 

interval 

until 

byday 

bymonthday 

byyearday 

byweekno 

bymonth 

wkst 



Specific time to match 

RFC 2445 Time Zone Identifier 

RFC 2445 Time Zone URL 



Start of interval (RFC 2445 DATE-TIME) 

End of interval (RFC 2445 DATE-TIME). 

Length of interval (RFC 2445 DURATION) 

Frequency of recurrence (one of "daily", 

"weekly", "monthly", or "yearly") 

How often the recurrence repeats 

Bound of recurrence (RFC 2445 DATE-TIME) 

List of days of the week 

List of days of the month 

List of days of the year 

List of weeks of the year 

List of months of the year 

First day of workweek 



Figure 6: Syntax of the time-switch node 



Time switches are based on a large subset of how recurring intervals 
of time are specified in the Internet Calendaring and Scheduling Core 
Object Specification (iCal COS), RFC 2445 [12]. 



This allows CPLs to be generated automatically from 
calendar books. It also allows us to re-use the extensive 
existing work specifying time intervals. 



The subset was designed with the goal that a time -switch 
can be evaluated --an instant can be determined to fall 
within an interval, or not -- in constant (O(l)) time. 

An algorithm to whether an instant falls within a given recurrence is 
given in Appendix A. 

The time-switch tag takes two optional parameters, tzid and tzurl, 
both of which are defined in RFC 2445 (Sections 4.8.3.1 and 4.8.3.5 
respectively) . The TZID is the identifying label by which a time zone 
definition is referenced. If it begins with a forward slash 
(solidus) , it references a to-be-defined global time zone registry; 
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otherwise it is locally-defined at the server. The TZURL gives a 
network location from which an up-to-date VTIMEZONE definition for 
the timezone can be retrieved. 

While TZID labels that do not begin with a forward slash are locally 
defined, it is RECOMMENDED that servers support at least the naming 
scheme used by Olson Time Zone database [13] . Examples of timezone 
databases that use the Olson scheme are the zoneinfo files on most 
Unix-like systems, and the standard Java TimeZone class. 

If a script is uploaded with a tzid and tzurl which the CPL server 
does not recognize or cannot resolve, it SHOULD diagnose and reject 
this at script upload time. If neither tzid nor tzurl are present, 
all non-UTC times within this time switch should be interpreted as 
being "floating" times, i.e. that they are specified in the local 
timezone of the CPL server. 



Because of daylight-savings-time changes over the course of 
a year, it is necessary to specify time switches in a given 
timezone. UTC offsets are not sufficient, or a time-of-day 
routing rule which held between 9 am and 5 pm in the 
eastern United States would start holding between 8 am and 
4 pm at the end of October. 

Authors of CPL servers should be careful to handle correctly the 
intervals when local time is discontinuous, at the beginning or end 
of daylight-savings time. Note especially that some times may occur 
more than once when clocks are set back. The algorithm in Appendix A 
is believed to handle this correctly. 

Time nodes specify a list of periods during which their output should 
be taken. They have two required parameters: dtstart, which specifies 
the beginning of the first period of the list, and exactly one of 
dtend or duration, which specify the ending time or the duration of 
the period, respectively. The dtstart and dtend parameters are 
formatted as iCal COS DATE-TIME values, as specified in Section 4.3.5 
of RFC 2445 [12]. Because time. zones are specified in the top-level 
time -switch tag, only forms 1 or 2 (floating or UTC times) can be 
used. The duration parameter is given as an iCal COS DURATION 
parameter, as specified in section 4.3.6 of RFC 2445. Both the DATE- 
TIME and the DURATION syntaxes are subsets of the corresponding 
syntaxes from ISO 8601 [14] . 

For a recurring interval, the duration parameter MUST be less than 
twenty-four hours. For non-recurring intervals, durations of any 
length are permitted. 
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If no other parameters are specified, a time node indicates only a 
single period of time. More complicated sets periods intervals are 
constructed as recurrences. A recurrence is specified by including 
the freq parameter, which indicates the type of recurrence rule. No 
parameters other than dt start, dtend, and duration SHOULD be 
specified unless freq is present. 

The freq parameter takes one of the following values: daily, to 
specify repeating periods based on an interval of a day or more; 
weekly, to specify repeating periods based on an interval of a week 
or more; monthly, to specify repeating periods based on an interval 
of a month or more; and yearly, to specify repeating periods based on 
an interval of a year or more. These values are not case-sensitive. 



The values secondly, minutely, and hourly are present in 
iCal, but were removed from CPL. 

The interval parameter contains a positive integer representing how 
often the recurrence rule repeats. The default value is "1", meaning 
every day for a daily rule, every week for a weekly rule, every month 
for a monthly rule and every year for a yearly rule. 

The until parameter defines an iCal COS DATE or DATE-TIME value which 
bounds the recurrence rule in an inclusive manner. If the value 
specified by until is synchronized with the specified recurrence, 
this date or date-time becomes the last instance of the recurrence. 
If specified as a date-time value, then it MUST be specified in an 
UTC time format. If not present, the recurrence is considered to 
repeat forever. 



iCal also defines a count parameter, which allows an 
alternate method of specifying a bound to a recurrence. 
This bound has been removed from CPL. Translating from full 
iCal recurrences to CPL recurrences requires that the count 
parameter be converted to an until parameter, which can be 
done by enumerating the recurrence and determining its 
final date. 

The byday parameter specifies a comma -separated list of days of the 
week. MO indicates Monday; TU indicates Tuesday; WE indicates 
Wednesday; TH indicates Thursday; FR indicates Friday; SA indicates 
Saturday; SU indicates Sunday. These values are not case-sensitive. 

Each byday value can also be preceded by a positive (+n) or negative 
(-n) integer. If present, this indicates the nth occurrence of the 
specific day within the monthly or yearly recurrence. For example, 
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within a monthly rule, +1M0 (or simply 1M0) represents the first 
Monday within the month, whereas -1M0 represents the last Monday of 
the month. If an integer modifier is not present, it means all days 
of this type within the specified frequency. For example, within a 
monthly rule, MO represents all Mondays within the month. 

The bymonthday parameter specifies a comma -separated list of days of 
the month. Valid values are 1 to 31 or -31 to -1. For example, -10 
represents the tenth to the last day of the month. 

The byyearday parameter specifies a comma-separated list of days of 
the year. Valid values are 1 to 366 or -366 to -1. For example, -1 
represents the last day of the year (December 31st) and -306 
represents the 306th to the last day of the year (March 1st). 

The byweekno parameter specifies a comma -separated list of ordinals 
specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. 
This corresponds to weeks according to week numbering as defined in 
ISO 8601 [14] . A week is defined as a seven day period, starting on 
the day of the week defined to be the week start (see wkst) . Week 
number one of the calendar year is the first week which contains at 
least four (4) days in that calendar year. This parameter is only 
valid for yearly rules. For example, 3 represents the third week of 
the year. 



Note: Assuming a Monday week start, week 53 can only occur 
when Thursday is January 1 or if it is a leap year and 
Wednesday is January 1. 

The bymonth parameter specifies a comma -separated list of months of 
the year. Valid values are 1 to 12. 

The wkst parameter specifies the day on which the workweek starts. 
Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant 
when a weekly recurrence has an interval greater than 1, and a byday 
parameter is specified. This is also significant in a yearly 
recurrence when a byweekno parameter is specified. The default value 
is MO, following ISO 8601 [14] . 



iCal also includes the Byxxx parameters bysecond, byminute, 
byhour, and bysetpos, which have been removed from CPL. 

If byxxx parameter values are found which are beyond the available 
scope (ie, bymonthday= " 3 0 " in February), they are simply ignored. 

Byxxx parameters modify the recurrence in some manner. Byxxx rule 
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parts for a period of time which is the same or greater than the 
frequency generally reduce or limit the number of occurrences of the 
recurrence generated. For example, freq="daily" bymonth="l" reduces 
the number of recurrence instances from all days (if the bymonth 
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parameter is not present) to all days in January. Byxxx parameters 
for a period of time less than the frequency generally increase or 
expand the number of occurrences of the recurrence. For example, 
freq= "yearly" bymonth= " 1 , 2 " increases the number of days within the 
yearly recurrence set from 1 (if bymonth parameter is not present) to 
2. 

If multiple Byxxx parameters are specified, then after evaluating the 
specified freq and interval parameters, the "Byxxx parameters are 
applied to the current set of evaluated occurrences in the following 
order: bymonth, byweekno, byyearday, bymonthday, and byday; then 
until is evaluated. 

Here is an example of evaluating multiple Byxxx parameters. 



<time dtstart="19970105T083000" duration="PT10M" 

freq= "yearly" interval="2" bymonth="l" byday="SU"> 



First, the interval="2 " would be applied to freq= "YEARLY" to arrive 
at "every other year." Then, bymonth="l" would be applied to arrive 
at "every January, every other year." Then, byday="SU" would be 
applied to arrive at "every Sunday in January, every other year." 
Then the time of day is derived from dtstart to end up in "every 
Sunday in January from 8:30:00 AM to 8:40:00 AM, every other year." 
Similarly, if the byday, bymonthday or bymonth parameter were 
missing, the appropriate day or month would have been retrieved from 
the dtstart parameter. 

The iCal COS RDATE, EXRULE and EXDATE recurrence rules are not 
specifically mapped to components of the time-switch node. Equivalent 
functionality to the exception rules can be attained by using the 
ordering of switch rules to exclude times using earlier rules; 
equivalent functionality to the additional -date RDATE rules can be 
attained by using sub nodes (see Section 9) to link multiple outputs 
to the same subsequent node. 

The not -present output is never true for a time switch. However, it 
MAY be included, to allow switch processing to be more regular. 

5.3.1 Motivations for the iCal Subset 
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(This sub-sub-section is non-normative.) 

The syntax of the CPL time -switch was based on that of the iCal COS 
RRULE, but as mentioned above, certain features were omitted and 
restrictions were added. Specifically: 

1. All recurrence intervals and rules describing periods less 
than a day were removed. These were the frequencies 
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secondly, minutely, and hourly, and the Byxxx rules 
bysecond, byminute, and byhour. 

2. The count and bysetpos parameters were removed. 

3. Durations were constrained to less than 24 hours for 
recurring intervals . 

These restrictions were added so that time switches could be resolved 
efficiently, in 0(1) time. This restriction means that it must be 
possible to resolve a time switch without having to enumerate all its 
recurrences from dtstart to the present interval. As far as we have 
been able to determine, it is not possible to test whether the count 
and bysetpos parameters are satisfied without performing such an 
enumeration. 

Constant running time of time switches also requires that a candidate 
starting time for a recurrence can be established quickly and 
uniquely, to check whether it satisfies the other restrictions. This 
requires that a recurrence's duration not be longer than its 
repetition interval, so that a given instant cannot fall within 
several consecutive repetitions of the recurrence. We guaranteed this 
by eliminating durations longer than 24 hours, and repetitions 
shorter than that period. The one-day point seemed to be the most 
generally useful place to place this division, as some investigation 
showed that many common calendaring applications do not support 
durations longer than a day, none that we found supported repetitions 
shorter than a day. Eliminating sub-day repetitions also greatly 
simplifies the handling of daylight-savings transitions. 

The algorithm given in Appendix A runs in constant time, and 
motivated the development of this iCal subset. 

5.4 Priority Switches 

Priority switches allow a CPL script to make decisions based on the 
priority specified for the original call. They are summarized in 
Figure 7. They are dependent on the underlying signalling protocol. 
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Node: 
Outputs : 
Parameters : 



priority- switch 

priority 

None 



Specific 



priority to match 



Output : 
Parameters : 



priority 
less 
greater 
equal 



Match if 
Match if 
Match if 



priority is less than specified 
priority is greater than specified 
priority is equal to specified 



Figure 7: Syntax of the priority-switch node 
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Priority switches take no parameters. 



The priority tags take one of the three parameters greater, less, and 
equal . The values of these tags are one of the following priorities : 
in decreasing order, emergency, urgent, normal, and non-urgent. These 
values are matched in a case-insensitive manner. Outputs with the 
less parameter are taken if the priority of the call is less than the 
priority given in the argument; and so forth. 

If no priority header is specified in a message, the priority is 
considered to be normal. If an unknown priority is specified in the 
call, it is considered to be equivalent to normal for the purposes of 
greater and less comparisons, but it is compared literally for equal 
comparisons . 

Since every message has a priority, the not-present output is never 
true for a priority switch. However, it MAY be included, to allow 
switch processing to be more regular. 

5.4.1 Usage of priority-switch with SIP 

The priority of a SIP message corresponds to the Priority header in 
the initial INVITE message. 

6 Location Modifiers 

The abstract location model of the CPL is described in Section 2.3. 
The behavior of several of the signalling operations (defined in 
■ Section 7) is dependent on the current location set specified. 
Location nodes add or remove locations from the location set. 

There are three types of location nodes defined. Explicit locations 
add literally-specified locations to the current location set; 
location lookups obtain locations from some outside source; and 
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location filters remove locations from the set, based on some 
specified criteria. 

6.1 Explicit Location 

Explicit location nodes specify a location literally. Their syntax is 
described in Figure 8 . 

Explicit location nodes are dependent on the underlying signalling 
protocol . 



Node: location 

Outputs: None (next node follows directly) 

Next node: Any node 

Parameters: url URL of address to add to locati 
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priority 
clear 



Priority of this location (0.0- 
Whether to clear the location s 



the new value 



Figure 8 : Syntax of the location node 



Explicit location nodes have three node parameters. The mandatory url 
parameter's value is the URL of the address to add to the location 
set. Only one address may be specified per location node; multiple 
locations may be specified by cascading these nodes. 

The optional priority parameter specifies a priority for the 
location. Its value is a floating-point number between 0.0 and 1.0. 
If it is not specified, the server SHOULD assume a default priority 
of 1.0. The optional clear parameter specifies whether the location 
set. should be cleared before adding the new location to it. Its value 
can be "yes" or "no", with "no" as the default. 

Basic location nodes have only one possible result, since there is no 
way that they can fail. (If a basic location node specifies a 
location which isn't supported by the underlying signalling protocol, 
the script server SHOULD detect this and report it to the user at the 
time the script is submitted.) Therefore, their XML representations 
do not have explicit output tags; the <location> tag directly 
contains another node. 

6.1.1 Usage of location with SIP 

All SIP locations are represented as URLs, so the locations specified 
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in location tags are interpreted directly. 

6.2 Location Lookup 

Locations can also be specified up through external means, through 
the use of location lookups. The syntax of these tags is given in 
Figure 9. 

Location lookup is dependent on the underlying signalling protocol. 
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Node 
Outputs 



lookup 

success 

not found 

failure 

source 

timeout 

use 

ignore 

clear 



Next node if lookup was successful 
Next node if lookup found no addresses 
Next node if lookup failed 
Source of the lookup 

Time to try before giving up on the lookup 

Caller preferences fields to use 

Caller preferences fields to ignore 

Whether to clear the location set before adding 



Parameters 
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the new values 



Output : 
Parameters : 



Output : 
Parameters : 



not found 
none 



Output : 
Parameters : 



failure 
none 



Figure 9: Syntax of the lookup node 



Location lookup nodes have one mandatory parameter, and four optional 
parameters. The mandatory parameter is source, the source of the 
lookup. This can either be a URI, or a non-URI value. If the value of 
source is a URI, it indicates a location which the CPL server can 
query to obtain an object with the text/uri-list media type (see the 
I ANA registration of this type, which also appears in RFC 2483 [15]) . 
The query is performed verbatim, with no additional information (such 
as URI parameters) added. The server adds the locations contained in 
this object to the location set. 

CPL servers MAY refuse to allow URI -based sources for location 
queries for some or all URI schemes. In this case, they SHOULD reject 
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the script at script upload time. 



There has been discussion of having CPL servers add URI 
parameters to the location request, so that (for instance) 
CGI scripts could be used to resolve them. However, the 
consensus was that this should be a CPL extension, not a 
part of the base specification. 

Non-URL sources indicate a source not specified by a URL which the 
server can query for addresses to add to the location set. The only 
non-URL source currently defined is registration, which specifies all 
the locations currently registered with the server. 

The lookup node also has four optional parameters. The timeout 
parameter specifies the time, in seconds, the script is willing to 
wait for the lookup to be performed. If this is not specified, its 
default value is 30. The clear parameter specifies whether the 
location set should be cleared before the new locations are added. 

The other two optional parameters affect the interworking of the CPL 
script with caller preferences and caller capabilities. By default, 
a CPL server SHOULD invoke the appropriate caller preferences 
filtering of the underlying signalling protocol, if the corresponding 
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information is available. The two parameters use and ignore allow the 
script to modify how the script applies caller preferences filtering. 
The specific meaning of the values of these parameters is 
signalling-protocol dependent; see Section 6.2.1 for SIP and Appendix 
B.5 for H.323. 

Lookup has three outputs: success, notfound, and failure. Notfound is 
taken if the lookup process succeeded but did not find any locations; 
failure is taken if the lookup failed for some reason, including that 
specified timeout was exceeded. If a given output is not present, 
script execution terminates and the default behavior is performed. 

Clients SHOULD specify the three outputs success, notfound, and 
failure in that order, so their script complies with the DTD given in 
Appendix C, but servers MAY accept them in any order. 

6.2.1 Usage of lookup with SIP 

Caller preferences for SIP are defined in "SIP Caller Preferences and 
Callee Capabilities" [16] . By default, a CPL server SHOULD honor any 
Accept-Contact and Reject -Contact headers of the original call 
request, as specified in that document. The two parameters use and 
ignore allow the script to modify the data input to the caller 
preferences algorithm. These parameters both take as their arguments 
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comma -separated lists of caller preferences parameters. If use is 
given, the server applies the caller preferences resolution algorithm 
only to those preference parameters given in the use parameter, and 
ignores all others; if the ignore parameter is given, the server 
ignores the specified parameters, and uses all the others. Only one 
of use and ignore can be specified. 

The addr-spec part of the caller preferences is always applied, and 
the script cannot modify it. 

If a SIP server does not support caller preferences and callee 
capabilities, if the call. request does not contain any preferences, 
or if the callee 's registrations do not contain any capabilities, the 
use and ignore parameters are ignored. 

6.3 Location Removal 

A CPL script can also remove locations from the location set, through 
the use of the remove -location node. The syntax of this node is 
defined in Figure 10. 

The meaning of this node is dependent on the underlying signalling 
protocol . 



Node: remove -location 
Outputs: None (next node follows directly) 
Next node: Any node 



http://tools.ietf.org/wg/iptel/draft-ietf-iptel-cpl/draft-ietf-iptel-cpl-04.txt 



9/14/05 



Page 23 of 60 



Parameters : 



location 

param 

value 



Location to remove 

Caller preference parameters to a 

Value of caller preference parame 



Figure 10: Syntax of the remove -location node 



A remove -location node removes locations from the location set. It is 
primarily useful following a lookup node. An example of this is 
given in Section 13.8. 

The remove- location node has three optional parameters. The parameter 
location gives the URL (or a signalling-protocol-dependent URL 
pattern) of location or locations to be removed from the set. If this 
parameter is not given, all locations, subject to the constraints of 
the other parameters, are removed from the set. 

If param and value are present, their values are comma -separated 
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lists of caller preferences parameters and corresponding values, 
respectively. The nth entry in the param list matches the nth entry 
in the value list. There MUST be the same number of parameters as 
values specified. The meaning of these parameters is signalling- 
protocol dependent. 

The remove -location node has no explicit output tags. In the XML 
syntax, the XML remove -location tag directly encloses the next node's 
tag. 

6.3.1 Usage of remove -location with SIP 

For SIP-based CPL servers, the remove -location node has the same 
effect on the location set as a Reject -Contact header in caller 
preferences [16] . The value of the location parameter is treated as 
though it were the addr-spec field of a Reject-Contact header; thus, 
an absent header is equivalent to an addr-spec of "*" in that 
specification. The param and value parameters are treated as though 
they appeared in the params field of a Reject -Location header, as " ; 
param=value" for each one. 

If the CPL server does not support caller preferences and callee 
capabilities, or if the callee did not supply any preferences, the 
param and value parameters are ignored. 

7 Signalling Operations 

Signalling operation nodes cause signalling events in the underlying 
signalling protocol. Three signalling operations are defined: 
"proxy," "redirect," and "reject." 
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7 . 1 Proxy 
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Proxy causes the triggering call to be forwarded on to the currently 
specified set of locations. The syntax of the proxy node is given in 
Figure 11. 

The specific signalling events invoked by the proxy node are 
signalling-protocol -dependent, though the general concept should 
apply to any signalling protocol. 



After a proxy operation has completed, the CPL server chooses the 
"best" response to the call attempt, as defined by the signalling 
protocol or the server's administrative configuration rules. 

If the call attempt was successful, CPL execution terminates and the 
server proceeds to its default behavior (normally, to allow the call 
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Node: 


proxy 




Outputs : 


busy 


Next node if call attempt returned "busy" 




noanswer 


Next node if call attempt was not answered before 




redirection 


Next node if call attempt was redirected 




failure 


Next node if call attempt failed 




default 


Default next node for unspecified outputs 


Parameters : 


timeout 


Time to try before giving up on the call attempt 




recurse 


Whether to recursively look up redirections 




ordering 


What order to try the location set in. 


Output : 


busy 




Parameters : 


none 




Output : 


noanswer 




Parameters : 


none 




Output : 


redirection 




Parameters : 


none 




Output : 


failure 




Parameters : 


none 




Output : 


default 




Parameters : 


none 





Figure 11: Syntax of the proxy node 



to be set up) . Otherwise, the next node corresponding to one of the 
proxy node's outputs is taken. The busy output is followed if the 
call was busy; noanswer is followed if the call was not answered 
before the timeout parameter expired; redirection is followed if the 
call was redirected; and failure is followed if the call setup failed 
for any other reason. 
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If one of the conditions above is true, but the corresponding output 
was not specified, the default output of the proxy node is followed 
instead. If there is also no default node specified, CPL execution 
terminates and the server returns to its default behavior (normally, 
to forward the best response upstream to the originator) . 



Note: CPL extensions to allow in-call or end-of-call 
operations will require an additional output, such as 
success, to be added. 
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If no locations were present in the set, or if the only locations in 
the set were locations to which the server cannot proxy a call (for 
example, "http" URLs), the failure output is taken. 

Proxy has three optional parameters. The timeout parameter specifies 
the time, in seconds, to wait for the call to be completed or 
rejected; after this time has elapsed, the call attempt is terminated 
and the noanswer branch is taken. If this parameter is not specified, 
the default value is 20 seconds if the proxy node has a noanswer or 
default output specified; otherwise the server SHOULD allow the call 
to ring for a reasonably long period of time (to the maximum extent 
that server policy allows) . 

The second optional parameter is recurse, which can take two values, 
yes or no. This specifies whether the server should automatically 
attempt to place further call attempts to telephony addresses in 
redirection responses that were returned from the initial server. 
Note that if the value of recurse is yes, the redirection output to 
the script is never taken. In this case this output SHOULD NOT be 
present. The default value of this parameter is yes. 

The third optional parameter is ordering. This can have three 
possible values: parallel, sequential, and first-only. This 
parameter specifies in what order the locations of the location set 
should be tried. Parallel asks that they all be tried simultaneously; 
sequential asks that the one with the highest priority be tried 
first, the one with the next -highest priority second, and so forth> 
until one succeeds or the set is exhausted. First -only instructs the 
server to try only the highest -priority address in the set, and then 
follow one of the outputs. The priority of locations in a set is 
determined by server policy, though CPL servers SHOULD honor the 
priority parameter of the location tag. The default value of this 
parameter is parallel. 

Once a proxy operation completes, if control is passed on to other 
nodes, all locations which have been used are cleared from the 
location set. That is, the location set is emptied of proxyable 
locations if the ordering was parallel or sequential; the highest- 
priority item in the set is removed from the set if ordering was 
first-only. (In all cases, non-proxyable locations such as "http" 
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URIs remain.) In the case of a redirection output, the new addresses 
to which the call was redirected are then added to the location set. 

7.1.1 Usage of proxy with SIP 

For SIP, the best response to a proxy node is determined by the 
algorithm of the SIP specification. The node's outputs correspond to 
the following events: 



Lennox/Schulzrinne [Page 27] 

□ 

Internet Draft CPL November 14, 2000 



busy A 486 or 600 response was the best response received to the 
call request. 

redirection A 3xx response was the best response received to the 
call request. 

failure Any other 4xx, 5xx, or 6xx response was the best 
response received to the call request. 

no-answer No final response was received to the call request 
before the timeout expired. 

SIP servers SHOULD honor the q parameter of SIP registrations and the 
output of the caller preferences lookup algorithm when determining 
location priority. 

7.2 Redirect 

Redirect causes the server to direct the calling party to attempt to 
place its call to the currently specified set of locations. The 
syntax of this node is specified in Figure 12. 

The specific behavior the redirect node invokes is dependent on the 
underlying signalling protocol involved, though its semantics are 
generally applicable. 



Node : redirect 
Outputs: None (no node may follow) 
Next node: None 

Parameters: permanent Whether the redirection should be 

considered permanent 



Figure 12 : Syntax of the redirect node 



Redirect immediately terminates execution of the CPL script, so this 
node has no outputs and no next node. It has one parameter, 
permanent, which specifies whether the result returned should 
indicate that this is a permanent redirection. The value of this 
parameter is either "yes" or "no" and its default value is "no." 
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7.2.1 Usage of redirect with SIP 



The SIP server SHOULD send a 3xx class response to a call request 
upon executing a redirect tag. If permanent was yes, the server 
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SHOULD send the response "301 Moved permanently"; otherwise it SHOULD 
send "302 Moved temporarily". 

7.3 Reject 

Reject nodes cause the server to reject the call attempt. Their 
syntax is given in Figure 13. The specific behavior they invoke is 
dependent on the underlying signalling protocol involved, though 
their semantics are generally applicable. 



Node: reject 
Outputs: None (no node may follow) 
Next node: None 
Parameters: status Status code to return 

reason Reason phrase to return 



Figure 13: Syntax of the reject node 



This immediately terminates execution of the CPL script, so this node 
has no outputs and no next node. 

This node has two arguments: status and reason. The status argument 
is required, and can take one of the values busy, notfound, reject, 
and error, or a signalling-protocol-defined status. 

The reason argument optionally allows the script to specify a reason 
for the rejection. 

7.3.1 Usage of reject with SIP 

Servers' which implement SIP SHOULD also allow the status field to be 
a numeric argument corresponding to a SIP status in the 4xx, 5xx, or 
6xx range. 

They SHOULD send the "reason" parameter in the SIP reason phrase. 

A suggested mapping of the named statuses is as follows. Servers MAY 
use a different mapping, though similar semantics SHOULD be 
preserved. 

busy: 486 Busy Here 

notfound: 404 Not Found 
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reject: 603 Decline 



error: 500 Internal Server Error 



8 Non- signalling Operations 

In addition to the signalling operations , the CPL defines several 
operations which do not affect and are not dependent on the telephony 
signalling protocol. 



The mail node causes the server to notify a user of the status of the 
CPL script through electronic mail . Its syntax is given in Figure 14 . 



Node : mail 

Outputs: None (next node follows directly) 

Next node: Any node 

Parameters: url Mailto url tc which the mail shou 



Figure 14 : Syntax of the mail node 



The mail node takes one argument: a mailto URL giving the address, 
and any additional desired parameters, of the mail to be sent. The 
server sends the message containing the content to the given url; it 
SHOULD also include other status information about the original call 
request and the CPL script at the time of the notification. 



Using a full mailto URL rather than just an e-mail address 
allows additional e-mail headers to be specified, such as 



url= "mailto : jonesOexample . com?subject=lookup%20f ailed" /> . 

Mail nodes have only one possible result, since failure of e-mail 
delivery cannot reliably be known in real-time. Therefore, its XML 
representation does not have output tags: the <mail> tag directly 
contains another node tag. 

Note that the syntax of XML requires that ampersand characters, "&", 
which are used as parameter separators in mailto URLs, be quoted as 
"&" inside parameter values (see Section C.12 of [3]). 

8.1.1 Suggested Content of Mailed Information 
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• This section presents suggested guidelines for the mail sent as a 
result of the mail node, for requests triggered by SIP. The message 
mailed (triggered by any protocol) SHOULD contain all this 
information, but servers MAY elect to use a different format. 

1. If the mailto URI did not specify a subject header, the 
subject of the e-mail is "[CPL]" followed by the subject 
header of the SIP request. If the URI specified a subject 
header, it is used instead. 

2. The From field of the e-mail is set to a CPL server 
configured address, overriding any From field in the mailto 
URI. 

3. Any Reply-To header in the URI is honored. If none is 
given, then an e-mail-ized version of the origin field of 
the request is used, if possible (e.g., a SIP From header 
with a sip: URI would be converted to an e-mail address by 
stripping the URI scheme) . 

4. If the mailto URI specifies a body, it is used. If none was 
specified, the body SHOULD contain at least the identity of 
the caller (both the caller's display name and address), 
the date and time of day, the call subject, and if 
available, the call priority. 

The server SHOULD honor the user's requested languages, and send the 
mail notification using an appropriate language and character set. 

8 . 2 Log 

The Log node causes the server to log information about the call to 
non-volatile storage. Its syntax is specified in Figure 15. 



Node : log 

Outputs: None (next node follows directly) 
Next node: Any node 
Parameters: name Name of the log file to use 

comment Comment to be placed in log file 



Figure 15 : Syntax of the log node 



Log takes two arguments, both optional: name, which specifies the 
name of the log, and comment, which gives a comment about the 
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information being logged. Servers SHOULD also include other 
information in the log, such as the time of the logged event, 
information that triggered the call to be logged, and so forth. Logs 
are specific to the owner of the script which logged the event. If 
the name parameter is not given, the event is logged to a standard, 
server-defined log file for the script owner. This specification does 
not define how users may retrieve their logs from the server. 

The name of a log is a logical name only, and does not necessarily 
correspond to any physical file on the server. The interpretation of 
the log file name is server defined, as is a mechanism to access 
these logs. The CPL server SHOULD NOT directly map log names 
uninterpreted onto local file names, for security reasons, lest a 
security-critical file be overwritten. 

A correctly operating CPL server SHOULD NOT ever allow the log event 
to fail. As such, log nodes can have only one possible result, and 
their XML representation does not have explicit output tags. A CPL 
<log> tag directly contains another node tag. 

9 Subactions 

XML syntax defines a tree. To allow more general call flow diagrams, 
and to allow script re-use and modularity, we define subactions. 

Two tags are defined for subactions: subaction definitions' and 
subaction references. Their syntax is given in Figure 16. 



Tag 
Subtags 
Parameters 



subaction 
Any node 



Name of this subaction 



Pseudo-node : 
Outputs : 
Parameters : 



sub 

None in XML tree 



Name of subaction to execute 



Figure 16: Syntax of subactions and sub pseudo-nodes 



Subactions are defined through subaction tags. These tags are placed 
in the CPL after any ancillary information (see Section 10) but 
before any top-level tags. They take one argument: id, a token 
indicating a script -chosen name for the subaction. 

Subactions are called from sub tags. The sub tag is a "pseudo-node" : 
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it can be used anyplace in a CPL action that a true node could be 
used. It takes one parameter, ref , the name of the subaction to be 
called. The sub tag contains no outputs of its own; control instead 
passes to the subaction. 
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References to subactions MUST refer to subactions defined before the 
current action. A sub tag MUST NOT refer to the action which it 
appears in, or to any action defined later in the CPL script. Top- 
level actions cannot be called from sub tags, or through any other 
means. Script servers MUST verify at the time the script is submitted 
that no sub node refers to any subaction which is not its proper 
predecessor. 



Allowing only back-references of subs forbids any sort of 
recursion. Recursion would introduce the possibility of 
non-terminating or non-decidable CPL scripts, a possibility 
our requirements specifically excluded. 

Every sub MUST refer to a subaction ID defined within the same CPL 
script. No external links are permitted. 

Subaction IDs are case sensitive. 



If any subsequent version or extension defines external 
linkages, it should probably use a different tag, perhaps 
XLink [17] . Ensuring termination in the presence of 
external links is a difficult problem. 

10 Ancillary Information 

No ancillary information is defined in the base CPL specification. If 
ancillary information, not part of any operation, is found to be 
necessary for a CPL extension, it SHOULD be placed within this tag. 

The (trivial) definition of the ancillary information tag is given in 
Figure 17. 



It may be useful to include timezone definitions inside CPL 
scripts directly, rather than referencing them externally 
with tzid and tzurl parameters. If it is, an extension 
could be defined to include them here. 



11 Default Behavior 
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Tag: ancillary 
Parameters: None 
Subtags : None 



Figure 17: Syntax of the ancillary tag 
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When a CPL node reaches an unspecified output, either because the 
output tag is not present, or because the tag is present but does not 
contain a node, the CPL server's behavior is dependent on the current 
state of script execution. This section gives the operations that 
should be taken in each case. 

no location modifications or signalling operations performed, 
location set empty: Look up the user's location through 
whatever mechanism the server would use if no CPL script 
were in effect. Proxy, redirect, or send a rejection 
message, using whatever policy the server would use in the 
absence of a CPL script. 

no location modifications or signalling operations performed, 

location set non-empty: (This can only happen for outgoing 
calls.) Proxy the call to the addresses in the location 
set. 

location modifications performed, no signalling operations: 
Proxy or redirect the call, whichever is the server's 
standard policy, to the addresses in the current location 
set. If the location set is empty, return notfound 
rejection. 

noanswer output of proxy, no timeout given: (This is a special 
case.) If the noanswer output of a proxy node is 
unspecified, and no timeout parameter was given to the 
proxy node, the call should be allowed to ring for the 
maximum length of time allowed by the server (or the 
request, if the request specified a timeout) . 

proxy operation previously taken: Return whatever the "best" 
response is of all accumulated responses to the call to 
this point, according to the rules of the underlying 
signalling protocol. 

12 CPL Extensions 



Lennox/Schulzrinne [Page 34] 

□ 

Internet Draft CPL November 14, 2000 



Servers MAY support additional CPL features beyond those listed in 
this document. Some of the extensions which have been suggested are a 
means of querying how a call has been authenticated; richer control 
over H.323 addressing; end-system or administrator- specif ic features; 
regular-expression matching for strings and addresses; mid-call or 
end-of-call controls; and the parts of iCal COS recurrence rules 
omitted from time switches. 

CPL extensions are indicated by XML namespaces [18] . Every extension 
MUST have an appropriate XML namespace assigned to it. All XML tags 
and attributes that are part of the extension MUST be appropriately 
qualified so as to place them within that namespace. 
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Tags or attributes in a CPL script which are in the global namespace 
(i.e., not associated with any namespace) are equivalent to tags and 
attributes in the CPL namespace "http://www.rfc- 
editor.org/rfc/rf cxxxx. txt" . 

A CPL server MUST reject any script which contains a reference to a 
namespace which it does not understand. It MUST reject any script 
which contains an extension tag or attribute which is not qualified 
to be in an appropriate namespace. 

A CPL script SHOULD NOT specify any namespaces it does not use. For 
compatibility with non-namespace-aware parsers, a CPL script SHOULD 
NOT specify the base CPL namespace for a script which does not use 
any extensions. 



A syntax such as 

<extension-switch> 

<extension has="http : //www. example . com/ f oo" > 

[extended things] 
</extension> 
<otherwise> 

[non-extended things] 
</otherwise> 
</extension-switch> 

was suggested as an alternate way of handling extensions. 
This would allow scripts to be uploaded to a server without 
requiring a script author to somehow determine which 
extensions a server supports. However, experience 
developing other languages, notably Sieve [19] , was that 
this added excessive complexity to languages. The 
extension- switch tag could, of course, itself be defined in 
a CPL extension. 
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It is unfortunately true that XML DTDs, such as the CPL DTD 
given in Appendix C, are not powerful enough to encompass 
namespaces, since the base XML specification (which defines 
DTDs) predates the XML namespace specification. XML schemas 
[20] are a work in progress to define a name space -aware 
method for validating XML documents, as well as improving 
upon DTDs' expressive power in many other ways. 

13 Examples 

13.1 Example: Call Redirect Unconditional 

The script in Figure 18 is a simple script which redirects all calls 
to a single fixed location. 
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<?xml version= "1 . 0" ?> 

<!DOCTYPE cpl PUBLIC " -//IETF//DTD RFCxxxx. CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

<incoming> 

< location url= " s ip : smi th@phone . example . com" > 

<redirect /> 
</location> 
</incoming> 
</cpl> 



Figure 18 : Example Script : Call Redirect Unconditional 



13.2 Example: Call Forward Busy/No Answer 

The script in Figure 19 illustrates some more complex behavior. We 
see an initial proxy attempt to one address, with further operations 
if that fails. We also see how several outputs take the same action 
subtree, through the use of subactions. 



13.3 Example: Call Forward: Redirect and Default 

The script in Figure 20 illustrates further proxy behavior. The 
server initially tries to proxy to a single address. If this attempt 
is redirected, a new redirection is generated using the locations 
returned. In all other failure cases for the proxy node, a default 
operation -- forwarding to voicemail -- is performed. 
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<?xml version="l . 0" ?> 

<!DOCTYPE cpl PUBLIC " - // IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 
<cpl> 

<subaction id= "voicemail "> 

<location url="sip : jones@voicemail .example.com" > 
<proxy /> 

</location> 
</subaction> 

<incoming> 

<location url="sip : j ones® jonespc. example. com" > 
<proxy timeout="8"> 
<busy> 

<sub ref= "voicemail" /> 
</busy> 
<noanswer> 

<sub ref= "voicemail" /> 
</noanswer> 
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< /proxy > 
</location> 
</incoming> 
</cpl> 



Figure 19: Example Script: Call Forward Busy/No Answer 



13.4 Example: Call Screening 

The script in Figure 21 illustrates address switches and call 
rejection, in the form of a call screening script. Note also that 
because the address-switch lacks an otherwise clause, if the initial 
pattern did not match, the script does not define any operations. The 
server therefore proceeds with its default behavior, which would 
presumably be to contact the user. 



13 . 5 Example : Priority and Language Routing 

The script in Figure 22 illustrates service selection based on a 
call's priority value and language settings. If the call request had 
a priority of "urgent" or higher, the default script behavior is 
performed. Otherwise, the language string field is checked for the 
string "es" (Spanish) . If it is present, the call is proxied to a 
Spanish- speaking operator; other calls are proxied to an English- 
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<?xml version= "1 . 0" ?> 

<!D0CTYPE cpl PUBLIC " -/ /IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd»> 

<cpl> 

<subaction id="voicemail"> 
</subaction> 

< incoming > 

<location url= " sip : j ones® j onespc . example . com" > 
<proxy> 

<redirection> 

<redirect /> 
</redirection> 
<default> 

<location url="sip : jones®voicemail . example . com" > 

<proxy /> 
</location> 
</default> 
< /proxy > 
</location> 
</incoming> 
</cpl> 
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Figure 20: Example Script: Call Forward: Redirect and Default 



<?xml version="l . 0" ?> 

<!DOCTYPE cpl PUBLIC " - / / IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

<incoming> 

<address-switch f ield="origin" subf ield="user" > 
oddress is=" anonymous "> 
<reject status="reject" 

reason="I don't accept anonymous calls" /> 

</address> 
< /address -switch> 
</ incoming^ 
</cpl> 



Figure 21: Example Script: Call Screening 
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speaking operator. 



<?xml version="1.0" ?> 

<!D0CTYPE cpl PUBLIC " -/ /IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

<incoming> 

<priority-switch> 

<priority greater= "urgent" /> 
<otherwise> 

<string- switch field= "language "> 
<string contains="es"> 

< location url="sip : spanishOoperator . example . com" > 

<proxy /> 
</location> 
</string> 
<otherwise> 

< location url= " sip : englishOoperator . example . com" > 

<proxy /> 
</location> 
</otherwise> 
</string-switch> 
</otherwise> 
< /priority- switch> 
</incoming> 
</cpl> 
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Figure 22: Example Script: Priority and Language Routing 



13.6 Example: Outgoing Call Screening 

The script in Figure 23 illustrates a script filtering outgoing 
calls, in the form of a script which prevent 1-900 (premium) calls 
from being placed. This script also illustrates subdomain matching. 

13.7 Example: Time-of-day Routing 

Figure 24 illustrates time-based conditions and timezones. 

13.8 Example: Location Filtering 

Figure 25 illustrates filtering operations on the location set. In 
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<?xml version= "1.0" ?> 

<!D0CTYPE cpl PUBLIC " - / / IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

<outgoing> 

<address -switch field= "original -destination" subf ield="tel"> 
<address subdomain-of ="1900"> 
<reject status="reject" 

reason="Not allowed to make 1-900 calls." /> 

</address> 
</address- switch? 
</outgoing> 
</cpl> 



Figure 23: Example Script: Outgoing Call Screening 



<?xml version= "1 . 0" ?> 

<!D0CTYPE cpl PUBLIC " -/ /IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

<incoming> 

< time -switch tzid="America/New_York" 

tzurl= "http : //zones . example . com/ tz/America/New_York" > 
<time dtstart="20000703T090000" duration= " PT8H" 
f req= "weekly " byday = "MO, TU, WE, TH, FR" > 
<lookup source="registration ,, > 
<success> 
<proxy /> 
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</success> 
</ lookup > 
</time> 
<otherwise> 

<location url="sip : jonesOvoicemail .example .com" > 

<proxy /> 
</location> 
</otherwise> 
</time-switch> 
</ incoming> 
</cpl> 



Figure 24: Example Script: Time-of-day Routing 



this example, we assume that version 0.9beta2 of the "Inadequate 
Software SIP User Agent" mis-implements some features, and so we must 
work around its problems. We assume, first, that the value of its 
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particular mobile device we may have registered, so we remove that 
location from the location set. Once these two operations have been 
completed, call setup is allowed to proceed normally. 



<?xml version= "1.0" ?> 

<!D0CTYPE cpl PUBLIC " - / / IETF/ /DTD RFCxxxx CPL 1.0//EN" »cpl.dtd"> 

<cpl> 

<incoming> 

<string- switch f ield= "user-agent "> 

<string is=" Inadequate Software SIP User Agent/ 0. 9beta2"> 
<lookup source="registration" ignore="f eature"> 
<success> 

•cremove- location location= " sip :me@mobile. provider .net" > 

<proxy /> 
</remove-location> 
</success> 
</ lookup > 
</string> 
</string-switch> 
</ incoming > 
</cpl> 



Figure 25: Example Script: Location Filtering 



13.9 Example: Non-signalling Operations 

Figure 26 illustrates non-signalling operations; in particular, 
alerting a user by electronic mail if the lookup server failed. The 
primary motivation for having the mail node is to allow this sort of 
out-of-band notification of error conditions, as the user might 
otherwise be unaware of any problem. 
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13.10 Example: Hypothetical Extensions 

The example in Figure 27 shows a hypothetical extension which 
implements distinctive ringing. The XML namespace 

"http://www.example.com/distinctive-ring" specifies a new node named 
ring. 

The example in Figure 2 8 implements a hypothetical new attribute for 
address switches, to allow regular-expression matches. It defines a 
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<?xml version="1.0" ?> 

<!D0CTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

< incoming > 

<lookup source= "http : //www . example . com/cgi -bin/locate . cgi ?user= j ones " 
timeout="8"> 
<success> 

<proxy /> 
</success> 
<failure> 

<mail url= "mailto : j onesOexample . com?sub j ect=lookup%20f ailed" / > 
</failure> 
</lookup> 
</ incoming > 
</cpl> 



Figure 26: Example Script: Non- signal ling Operations 



<?xml version="l . 0" ?> 

<!D0CTYPE cpl PUBLIC " - / / IETF/ /DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl xmlns= "http: //www. ietf.org/internet-drafts/draf t-ietf-iptel-cpl-03.txt" 
xmlns :dr="http: //www. example . com/distinctive-ring"> 
< incoming > 

<address-switch f ield="origin"> 

<address is= " sip :boss@example . com" > 

<dr:ring ringstyle= "warble" /> 
</address> 
</address-switch> 
</incoming> 
</cpl> 



Figure 27: Example Script: Hypothetical Distinctive-Ringing Extension 
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new attribute regex for the standard address node. In this example 
the global namespace is not specified. 



13.11 Example: A Complex Example 

Finally, Figure 2 9 is a complex example which shows the sort of 
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<?xml version="l . 0" ?> 

<!DOCTYPE cpl PUBLIC "-//IETF// DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> 

<cpl> 

<incoming> 

oddress- switch f ield= "origin" subf ield="user" 
xmlns : re= "http : //www . example . com/ regex " > 
oddress re:regex=" (.*. smith | .*. jones) "> 
<reject status=" reject" 

reason= "I don't want, to talk to Smiths or Joneses" /> 

</address> 
</address-switch> 
</ incoming > 
</cpl> 



Figure 28: Example Script: Hypothetical Regular-Expression Extension 



sophisticated behavior which can be achieved by combining CPL nodes. 
In this case, the user attempts to have his calls reach his desk; if 
he does not answer within a small amount of time, calls from his boss 
are forwarded to his mobile phone, and all other calls are directed 
to voicemail. If the call setup failed, no operation is specified, 
so the server's default behavior is performed. 



14 Security Considerations 

The CPL is designed to allow services to be specified in a manner 
which prevents potentially hostile or mis -configured scripts from 
launching security attacks, including denial-of -service attacks. 
Because script runtime is strictly bounded by acyclicity, and because 
the number of possible script operations are strictly limited, 
scripts should not be able to inflict damage upon a CPL server. 

Because scripts can direct users' telephone calls, the method by 
which scripts are transmitted from a client to a server MUST be 
strongly authenticated. Such a method is not specified in this 
document . 

Script servers SHOULD allow server administrators to control the 
details of what CPL operations are permitted. 
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15 I ANA Considerations 

This document registers the MIME type application/cpl+xml . See 
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<?xml version="l . 0" ?> 

<!D0CTYPE cpl PUBLIC " - / / IETF/ /DTD RFCXXXX CPL 1.0//EN" "cpl.dtd"> 
<cpl> 

<subaction id="voicemail"> 

< location url="sip : jonesSvoicemail . example . com" > 
<redirect /> 

</location> 
</subaction> 

<incoming> 

< location url="sip : jonesOphone . example . com" > 
<proxy timeout="8"> 
<busy> 

<sub ref ="voicemail" /> 
</busy> 
<noanswer> 

< addre s s - s wi tch f i eld= "origin " > 

<address is= " s ip : boss@example . com" > 
<location url="tel : +19175551212"> 

<proxy /> 
</location> 
</address> 
<otherwise> 

<sub ref ="voicemail" /> 
</otherwise> 
</address-switch> 
</noanswer> 
< /proxy > 
</location> 
</incoming> 
</cpl> 



Figure 29: Example Script: A Complex Example 



Section 3.2. 
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specification of Sieve [19] , a language for user filtering of 
electronic mail messages. 
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A An Algorithm for Resolving Time Switches 

The following algorithm resolves, in constant time, whether a given 
instant falls within a repetition of a time-switch recurrence. Open- 
source Java code implementing this algorithm is available on the 
world wide web at <http://www.cs.columbia.edu/-lennox/Cal-Code/> 



1. Compute the time of the call, in the timezone of the time 
switch. (No step after this needs to consider time zones 

all calculations are done using continuously -running 
standard Gregorian time.) 

2. If the call time is earlier than dtstart, fail N0MATCH. 

3. If the call time is less than duration after dtstart, 
succeed MATCH. 

4 . Determine the smallest unit specified in a byxxx rule or by 
the freq. Call this the Minimum Unit. Determine the 
previous instant (before the call time) when all the time 
units smaller than the minimum unit are the same as those 
of dtstart. (For all minimum units, the time -of -day must be 
the same as dtstart. If the minimum unit is a week, the 
day-of -the-week must be the same as dtstart. If the minimum 
unit is a month, the day-of -the -month must be the same as 
dtstart. If the minimum unit is a year, the month and day- 
of -month must both be the same as dtstart. (Note that this 
means it may be necessary to roll back more than one 
minimum unit -- if the minimum unit is a month, then some 
months do not have a 31st (or 30th or 29th) day,- if the 
minimum unit is a year, then some years do not have a 
February 2 9th. In the Gregorian calendar, it is never 
necessary to roll back more than two months, or eight years 
(four years between 1904 and 2096).) 
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Call this instant the Candidate Start Time. 

5. If the time between the candidate start time and the call 
time is more than the duration, fail NOMATCH. 

6. If the candidate start time is later than the until 
parameter of the recurrence, fail NOMATCH. 

7. Call the unit of the freq parameter of the recurrence the 
Frequency Unit. Determine the frequency unit enclosing the 
Candidate Start Time, and that enclosing dtstart. Calculate 
the number of frequency units that have passed between 
these two times. If this is not a multiple of the interval 
parameter, fail NOMATCH. 

8. For every byxxx rule, confirm that the candidate start time 
matches one of the options specified by that byxxx rule. If 
not, fail NOMATCH. 

9. Succeed MATCH. 

B Suggested Usage of CPL with H.323 

This appendix gives a suggested usage of CPL with H.323 [2] . Study 
Group 16 of the ITU, which developed H.323, is proposing to work on 
official CPL mappings for that protocol. This section is therefore 
not normative. 

B.l Usage of address -switch with H.323 

Address switches are specified in Section 5.1. This section specifies 
the mapping between H.323 messages and the fields and subfields of 
address -switches 

For H.323, the origin address corresponds to the alias addresses in 
the sourceAddress field of the Setup-UUIE user-user information 
element, and to the Q.931 [21] information element "Calling party 
number." If both fields are present, or if multiple aliases addresses 
for sourceAddress are present, which one has priority is a matter of 
local server policy; the server SHOULD use the same resolution as it 
would use for routing decisions in this case. Similarly, the 
destination address corresponds to the alias addresses of the 
destinationAddress field, and to the Q.931 information element 
"Called party number." 

The original -destination address corresponds to the "Redirecting 
number" Q.931 information element, if it is present; otherwise it is 
the same as the destination address. 
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The mapping of H.323 addresses into subfields depends on the type of 
the alias address. An additional subfield type, alias-type, is 
defined for H.323 servers, corresponding to the type of the address. 
Possible values are dialedDigits , h323-ID, url-ID, transportID, 
email-ID, partyNumber, mobileUIM, and Q.931IE. If future versions of 
the H.323 specification define additional types of alias addresses, 
those names MAY also be used. 

In versions of H.323 prior to version 4, dialedDigits was known as 
el64. The two names SHOULD be treated as synonyms. 

The value of the address-type subfield for H.323 messages is "h323" 
unless the alias type is url-ID and the URL scheme is something other 
than h32 3; in this case the address -type is the URL scheme, as 
specified in Section 5.1.1 for SIP. 

An H.323 -aware CPL server SHOULD map the address subfields from the 
primary alias used for routing. It MAY also map subfields from other 
aliases, if subfields in the primary address are not present. 

The following mappings are used for H.323 alias types: 

dialedDigits, partyNumber, mobileUIM, and Q.931IE: the tel and 
user subfields are the string of digits, as is the 
"entire -address" form. The host and port subfields are not 
present. 

url-ID: the same mappings are used as for SIP, in Section 5.1.1. 

h323-ID: the user field is the string of characters, as is the 

"entire-address" form. All other subfields are not present. 

email -ID: the user and host subfields are set to the 

corresponding parts of the e-mail address. The port and tel 
subfields are not present. The "entire-address" form 
corresponds to the entire e-mail address. 

transportID: if the TransportAddress is of type "ipAddress," 

"ipSourceRoute, " or "ip6Address, " the host subfield is set 
to the "ip" element of the sequence, translated into the 
standard IPv4 or IPv6 textual representation, and the port 
subfield is set to the "port" element of the sequence 
represented in decimal. The tel and user fields are not 
present. The "entire-address" form is not defined. The 
representation and mapping of transport addresses is not 
defined for non-IP addresses. 

H.323 version 4 [22] and the Internet -Draft draf t-levin-iptel-h323- 
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url-scheme-00 [23] define a "h323" URI scheme. This appendix defines 
a mapping for these URIs onto the CPL address -switch subfields, as 
given in Section 5.1. Neither of these documents has yet been 
formally published in a final form, so this appendix is non- 
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normative . 

For h323 URIs, the the user, host, and port subfields are set to the 
corresponding parts of the H.323 URL. The tel subfield is not 
present. The "entire-address" form corresponds to the entire URI. 

This mapping MAY be used both for h323 URIs in an h323 url-ID address 
alias, and for h323 URIs in SIP messages. 

B.2 Usage of string-switch with H.323 

For H.323, the string-switch node (see Section 5.2) is used as 
follows. The field language corresponds to the H.323 UUIE language, 
translated to the format ' specif ied for that field. The field display 
corresponds to the Q.931 information element of the same name, copied 
verbatim. The fields subject, organization, and user-agent are not 
used and are never present. 



The display IE is conventionally used for Caller-ID 
purposes, so arguably it should be mapped to the display 
subfield of an address -match with the field originator. 
However, since a) it is a message-level information 
element, not an address-level one, and b) the Q.931 
specification [21] says only that " [t]he purpose of the 
Display information element is to supply display 
information that may be displayed by the user," it seems to 
be more appropriate to allow it to be matched in a string - 
switch instead. 

B.3 Usage of priority-switch with H.323 

All H.323 messages are considered to have priority normal for the 
purpose of a priority switch (see Section 5.4) . 

B.4 Usage of location with H.323 

Locations in explicit location nodes (Section 6.1) are specified as 
URLs. Therefore, all locations added in this manner are interpreted 
as being of alias type url-ID in H.323. 

Specifications of other H.323 address alias types will require a CPL 
extension (see Section 12) . 
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B.5 Usage of lookup with H.323 

For location lookup nodes (Section 6.2), the registration lookup 
source corresponds to the locations registered with the server using 
RAS messages. 

As H.323 currently has no counterpart of SIP caller preferences and 
callee capabilities, the use and ignore parameters of the lookup node 
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are ignored. 

B.6 Usage of remove -location with H.323 

For location removal nodes (Section 6.3), only literal URLs can be 
removed. No URL patterns are defined. 

As H.323 currently has no counterpart of SIP caller preferences and 
callee capabilities, the param and value parameters of the remove- 
location node are ignored. 

C The XML DTD for CPL 

This section includes a full DTD describing the XML syntax of the 
CPL. Every script submitted to a CPL server SHOULD comply with this 
DTD. However, CPL servers MAY allow minor variations from it, 
particularly in the ordering of the outputs of nodes. Note that 
compliance with this DTD is not a sufficient condition for 
correctness of a CPL script, as many of the conditions described 
above are not expressible in DTD syntax. 
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<?xml version="l . 0" encoding="US-ASCII" ?> 



Draft DTD for CPL, corresponding to 
draft -ietf -iptel-cpl- 01. 



< ! - - Nodes . - - > 

<!-- Switch nodes --> 

< ! ENTITY % Switch ' address -switch | string-switch | time- switch | 
priority-switch' > 
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<!-- Location nodes --> 

< ! ENTITY % Location 1 location| lookup| remove -location" > 
<!-- Signalling action nodes --> 

<! ENTITY % SignallingAction ' proxy | redirect | reject ' > 

<!-- Other actions --> 

< ! ENTITY % OtherAction 'mail | log' > 

<!-- Links to subactions --> 
<! ENTITY % Sub -sub' > 

<!-- Nodes are one of the above four categories, or a subaction. 

This entity (macro) describes the contents of an output. 

Note that a node can be empty, implying default action. --> 
< ! ENTITY % Node ■ (%Location; | %Switch; j %SignallingAction; | 

%OtherAction; | %Sub; ) ? • > 



<!-- Switches: choices a CPL script can make. --> 

<!-- All switches can have an 'otherwise* output. --> 
<! ELEMENT otherwise ( %Node; ) > 

<!-- All switches can have a ' not -present • output. --> 
<! ELEMENT not -present ( %Node; ) > 

<!-- Address-switch makes choices based on addresses. --> 

< ! ELEMENT address-switch ( (address | not-present) +, otherwise? ) > 

<!-- <not-present> must appear at most once --> 

< ! ATTLIST address -switch 

field CDATA # REQUIRED 

subfield CDATA #IMPLIED 
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<! ELEMENT address ( %Node; ) > 

<! ATTLIST address 

is CDATA #IMPLIED 

contains CDATA #IMPLIED 

subdomain-of CDATA #IMPLIED 
> <!-- Exactly one of these three attributes must appear --> 
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<!-- String-switch makes choices based on strings. --> 

< ! ELEMENT string-switch ( ( string | not -present) +, otherwise? ) > 
<!-- <not-present> must appear at most once --> 
<! ATTLIST string-switch 

field CDATA #REQUIRED 
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<! ELEMENT string ( %Node; ) > 
< ! ATTLIST string 

is CDATA #IMPLIED 

contains CDATA #IMPLIED 

> <!-- Exactly one of these two attributes must appear --> 

<!-- Time -switch makes choices based on the current time. --> 

< ! ELEMENT time-switch ( (time | not -present) +, otherwise? ) > 
<! ATTLIST time-switch 

tzid CDATA #IMPLIED 

tzurl CDATA #IMPLIED 



<! ELEMENT time ( %Node; ) > 

<!-- Exactly one of the two attributes "dtend" and "duration" 
must occur. --> 

<!-- The value of "freq" is (daily | weekly | monthly | yearly) . It is 
case-insensitive, so it is not given as a DTD switch. --> 
<!-- None of the attributes following freq are meaningful unless freq 
appears . - - > 

<!-- The value of "wkst" is (MO | TU | WE | TH | FR | SA | SU) . It is 

case-insensitive, so it is not given as a DTD switch. --> 
<! ATTLIST time 



dtstart 


CDATA 


#REQUIRED 


dtend 


CDATA 


#IMPLIED 


duration 


CDATA 


#IMPLIED 


freq 


CDATA 


#IMPLIED 


until 


CDATA 


# IMPLIED 


interval 


CDATA 
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byday 


CDATA 


# IMPLIED 


bymonthday 


CDATA 


#IMPLIED 


byyearday 


CDATA 


# IMPLIED 


byweekno 


CDATA 


#IMPLIED 


bymonth 


CDATA 


#IMPLIED 


wkst 


CDATA 


"MO" 



<!-- Priority- switch makes choices based on message priority. --> 

<! ELEMENT priority- switch ( (priority | not-present) +, otherwise? ) > 
<!-- <not-present> must appear at most once --> 

< ! ENTITY % PriorityVal ' (emergency (urgent | normal | non-urgent) ' > 
<! ELEMENT priority ( %Node; ) > 

<!-- Exactly one of these three attributes must appear --> 
<! ATTLIST priority 
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less %PriorityVal; #IMPLIED 

greater %PriorityVal ; # IMPLIED 

equal CDATA #IMPLIED 



<!-- Locations: ways to specify the location a subsequent action 
(proxy, redirect) will attempt to contact. --> 

<! ENTITY % Clear 'clear (yes | no) "no"' > 

<! ELEMENT location ( %Node; ) > 
< ! ATTLIST location 

url CDATA #REQUIRED 

priority CDATA #IMPLIED 

%Clear; 



<! ELEMENT lookup ( success , notfound? , failure? ) > 
<! ATTLIST lookup 

source CDATA ^REQUIRED 

timeout CDATA "30" 

use CDATA #IMPLIED 

ignore CDATA #IMPLIED 

%Clear; 



success ( %Node; ) > 
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<! ELEMENT notfound ( %Node; ) > 
<! ELEMENT failure ( %Node; ) > 

< ! ELEMENT remove -location ( %Node; ) > 

<! ATTLIST remove -location 

param CDATA # IMPLIED 

value CDATA # IMPLIED 

location CDATA #IMPLIED 



<!-- Signalling Actions: call -signalling actions the script can 
take. --> 

<! ELEMENT proxy ( busy? , noanswer? , redirection? , failure? , default? ) > 

<!-- The default value of timeout is "20" if the <noanswer> output 

exists. --> 
<! ATTLIST proxy 

timeout CDATA #IMPLIED 

recurse (yes | no) "yes" 

ordering CDATA "parallel" 
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<! ELEMENT busy ( %Node; ) > 

< ! ELEMENT noanswer ( %Node ; ) > 

< ! ELEMENT redirection ( %Node; ) > 

<!-- "failure" repeats from lookup, above. --> 

<! ELEMENT default ( %Node; ) > 

<! ELEMENT redirect EMPTY > 
< ! ATTLIST redirect 

permanent (yes | no) "no" 



<!-- Statuses we can return --> 
< ! ELEMENT reject EMPTY > 

<!-- The value of "status" is (busy | notfound | reject | error) , or a SIP 

4xx- 6 xx status. --> 
<! ATTLIST reject 

Status CDATA # REQUIRED 

reason CDATA # IMPLIED 



<!-- Non- signalling actions: actions that don't affect the call --> 
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<! ELEMENT mail ( %Node; ) > 
<! ATTLIST mail 

url CDATA #1 



# REQUIRED 



<! ELEMENT log ( %Node; ) > 

<! ATTLIST log 

name CDATA i 

comment CDATA 1 



# IMPLIED 
# IMPLIED 



<!-- Calls to subactions 



- - > 



<! ELEMENT sub EMPTY > 
<! ATTLIST sub 

ref IDREF 



#REQUIRED 



<!-- Ancillary data --> 



<! ENTITY % Ancillary 'ancillary?' > 



<! ELEMENT ancillary EMPTY > 



<!-- Subactions --> 
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<! ENTITY % Subactions 1 subaction* ' > 

<! ELEMENT subaction ( %Node; )> 
< ! ATTLIST subaction 

id ID #REQUIRED 



<!-- Top-level actions --> 

< ! ENTITY % TopLevelActions ' outgoing?, incoming? 1 > 

<! ELEMENT outgoing ( %Node ; )> 

<! ELEMENT incoming ( %Node; )> 

<!-- The top-level element of the script. --> 

< ! ELEMENT cpl ( %Ancillary ; , %Subactions ; , %TopLevelActions ; ) > 
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D Changes from Earlier Versions 



[Note to RFC Editor: please remove this appendix before 
publication as an RFC] 

D.l Changes from Draft -03 

The changebars in the Postscript and PDF versions of this document 
indicate significant changes from this version. 

o Removed an obsolete reference to a usage in examples which 
wasn't actually used anywhere. 

o Added forward references to remove -location, mail and log, as 
well as location, in the XML syntax as examples of nodes that 
don't have explicit output tags. 

o Made the usage of some terminology more consistent: "output" 
vs. "next node"; "action" vs. "operation" vs. "behavior"; 
"sub-actions" and "subactions"; "other operations" and "non- 
call operations" and "non- signal ling operations"; "meta- 
information" and "ancillary information." 

o The tel subfield of addresses which come from sip URIs should 
have its visual separators stripped. 

o The default value of the priority value of the location node 
is 1.0. 

o Corrected the media type of a set of URIs to text/uri-list, 
and added a reference to it . 
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o Added some wording clarifying how URI -based lookup queries 
work . 

o Corrected the syntax of duration parameter in the examples . 

o Performed some pre -RFC textual cleanups (e.g. removing the 
reference to the Internet -Draft URL from the XML namespace 
identifier) . 

o Re -worded text in the description of the Ancillary tag which 
implied that information could be placed in that node in the 
base CPL specification. Clarified that the tag is for use by 
extensions only. 

o Expunged some references to sub-daily recurrences which had 



accidentally been left in the text. 

o Updated bibliography to refer to the latest versions of the 
cited documents. 

o Fixed a number of typographical errors. 



D.2 Changes from Draft -02 

o Reduced time -switches from the full iCal recurrence to an iCal 



subset. Added an appendix giving an algorithm to resolve 
time-switches. 

o Added the extension mechanism. 

c Made explicit how each node is dependent on protocol handling. 
Separated out protocol-specific information -- for SIP in 
subsections of the main text, for H.323 in a non-normative 
appendix . 

o Clarified some address mapping rules for H.323. 

o Corrected the name of the "Redirecting number" in Q.931. 

o Clarified that address matching on the password subfield is 
case-sensitive . 

o Added a recommendation that TZID labels follow the usage of 
the Olson database. 

o Added the priority parameter to location nodes. 

o Added the default output to the proxy node. 

o Made the meaning of the proxy node's outputs explicit. 
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o Added suggested content for the e-mail generated by mail 
nodes . 

o Pointed out that must be escaped in XML (this is relevant 

for mailto URIs) . 

o Pointed out that log names are logical names, and should not 
be interpreted as verbatim filenames. 

o Added some examples . 

o Clarified some wording. 
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o Fixed some typographical errors. 

D.3 Changes from Draft -01 

o Completely re-wrote changes to time switches: they are now 
based on iCal rather than on crontab. 

o Timezone references are now defined within time switches 

rather than in the ancillary section. The ancillary section is 
now empty, but still defined for future use. To facilitate 
this, an explicit ancillary tag was added. 

o Added XML document type identifiers (the public identifier and 
the namespace) , and MIME registration information. 

o Clarified that the not -present output can appear anywhere in a 
switch. 

o Re-wrote H.323 address mappings. Added the alias-type subfield 
for H.323 addresses. 

o Added the language and display string switch fields. 

o Clarified why useless not-present outputs can appear in time 
and priority switches . 

o Added the clear parameter to location and lookup nodes. (It 
had been in the DTD previously, but not in the text.) 

o Weakened support for non -validating scripts from SHOULD to 
MAY, to allow the use of validating XML parsers. 

o Added redirection output of proxy nodes. 

o Clarified some aspects of how proxy nodes handle the location 
set. 

o Added permanent parameter of redirect nodes. 

o Add example script for outgoing call screening (from Kenny 
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Horn) 

o Updated example scripts to use the public identifier. 

o Add omitted tag to example script for call forward busy/no 
answer 

o Clarified in introduction that this document mainly deals with 
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servers. 

o Updated reference to RFC 2824 now that it has been published. 

o Added explanatory text to the introduction to types of nodes. 

o Numerous minor clarifications and wording changes. 

o Fixed copy-and-paste errors, typos. 

D.4 Changes from Draft -00 

o Added high-level structure; script doesn't just start at a 
first action. 

o Added a section giving a high-level explanation of the 
location model. 

o Added informal syntax specifications for each tag so people 
don't have to try to understand a DTD to figure out the 
syntax. 

o Added subactions, replacing the old link tags. Links were far 
too reminiscent of gotos for everyone's taste. 

o Added ancillary information section, and timezone support. 

o Added not-present switch output. 

o Added address switches. 

o Made case-insensitive string matching locale - independent . 
o Added priority switch. 

o Deleted "Other switches" section. None seem to be needed, 
o Unified url and source parameters of lookup, 
o Added caller prefs to lookup, 
o Added location filtering. 

o Eliminated "clear" parameter of location setting. Instead, 
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proxy "eats" locations it has used. 



o Added recurse and ordering parameters to proxy. 
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o Added default value of timeout for proxy. 

o Renamed response to reject. 

o Changed notify to mail, and simplified it. 

o Simplified log, eliminating its failure output. 

o Added description of default actions at various times during 
script processing. 

o Updated examples for these changes. 

o Updated DTD to reflect new syntax. 
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ELEMENTS; FIND href ATTRIBUTES IN 
EACH CHILD LOCATOR OR DOCUMENT 
ELEMENT START-TAG 
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cL_ 

REMOVE INLINE ELEMENT START-TAG 
AND END-TAG FROM DOCUMENT 




RESOLVE href ATTRIBUTES TO FULL ADDRESS; 
COMPARE TO ALLOWED URI LIST; DELETE 
href ATTRIBUTES NOT ALLOWED FROM 
ELEMENT START-TAG 



FIND ALL INSTANCES 
OF href ATTRIBUTE 
IN THE ELEMENT START-TAG 
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PARSE DOCUMENT; USE 
xml: link ATTRIBUTE TO LOCATE 
ALL Xlink ELEMENTS; STORE 
ELEMENTS IN LIST. 
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METHOD AND APPARATUS FOR 
CONTROLLING BROWSER 
FUNCTIONALITY IN THE CONTEXT OF AN 
APPLICATION 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention includes methods and apparatus relating 
generally to browsing markup language documents across a 
network from within the context of a client application 
program, and specifically to restricting access only to 
allowed network resources and to allowed browser interface 
functions. 

2. Description of Related Art 

The public Internet and private intranets allow client 
programs on one computer to exchange information with 
server programs on other computers. World Wide Web 
(WWW) browsers are a type of client program that provide 
easy-to-use, virtually standardized, graphical access for 
browsing hypertext information formatted in markup lan- 



However, new markup languages are being introduced for 
specialized and general use. For example, special markup 
languages are being developed which are designed for use in 
consumer appliances. A newer general markup language is 
the extensible Markup Language (XML), being developed 
by the World Wide Web Consortium (W3C). XML may 
become a virtually universal markup language of the Inter- 
net in the future. Most producers of commercial browser 
have committed to supporting XML in future releases. 

' In detail, XML is a restricted form of the Standard 
Generalized Markup Language (SGML), which is also 
designed for use on the WWW. XML has many potential 
applications such as separation of structure from 
presentation, intelligent searching, messaging formats, and 

> data o 



However, most business applications perform other non- 
browsing tasks and require specialized interfaces. Attempts 
to provide a browser-like interface for application-oriented 25 
business tasks are likely to lead to undesirable user inter- 
faces. See, e.g., Nielson, 1998, "Does Internet=Web?", 
Jakob Nielson's Alertbox for Sep. 20, 1998. For example, 
e-mail applications like Lotus Notes, Outlook Express or 
Eudora are more professional with greater functionality than 30 
simple browser-like WWW e-mail interfaces (e.g., 
Hotmail). Likewise, other vertical market stand-alone busi- 
ness applications provide more features and functions than 
can be supported in a standard browser. 

However, it is often useful to provide for markup lan- 
guage browsing while remaining in the application context. 
In one alternative, the application may have a sub-window 
with some of the functionality of a standard browser. This 
window is not a separate window but is an embedded 4Q 
window that is an integral part of the application. Such a 
feature allows browsing of hypertext information without 
needing to exit the application and starting a separate 
browser application, such as Navigator of Netscape Corp. or 
Internet Explorer of Microsoft. 45 

Accessing and displaying markup language documents in 
the application context is typically different from standard 
browsing sessions. In standard browsing, a user can enter 
any Uniform Resource Identifier (URI) or click on any 
displayed link to access any desired content or resource. See, 50 
e.g., Internet Engineering Task Force, 1994, Uniform 
Resource Locators (URLs) RFC 1738; Internet Engineering 
Task Force, 1995, Relative Uniform Resource Locators — 
RFC 1808. However, in order to remain productive, brows- 
ing from the application context, should typically be focused 55 
and related to the application. For example, it can be more 
productive to permit access only to relevant documents and 
resources. 

Accordingly, it is important that any browser functionality 
embedded in the application context be configurable for 60 
focused productive use. 

Markup languages are widely used, especially for Internet 
content. Generally, markup languages are documents with 
text, images, and embedded markup tags which specify the 
desired display formatting of the document. In the past, 65 
Internet markup language hypertext documents have been 
largely limited to the Hypertext Markup Language (HTML). 



XML became a W3C recommendation in February 1998. 
See, e.g., World Wide Web Consortium, 1998, extensible 
Markup Language (XML) Version 1.0, Recommendation 
10. The W3C is developing a number of XML-related 
standards. An important standard is the XML Linking 
Language, or XLink. See, e.g., World Wide Web 
Consortium, 1998, XML Linking Language (XLink), Work- 
ing Draft 3-March. XLink describes linking information 
constructs that can be inserted into XML resources or 
documents to describe links between resources. XLink uses 
XML syntax to create one directional links (like HTML) as 
well as more complex multidirectional links. 

Other XML standards include the extensible Stylesheet 
Language (XSL) being designed for presentation of XML 
documents. See, e.g., World Wide Web Consortium, 1998, 
extensible Stylesheet Language (XSL), Version 1.0. XML 
name spaces are being designed to provide a simple method 
for qualifying element and attribute names used in XML 
documents by associating them with name spaces identified 
by URI references. See, e.g., World Wide Web Consortium, 
1998, Name spaces in XML. The Document Object Model 
(DOM) is designed for modeling document elements as 
objects and for providing an interface allowing programs 
and scripts to dynamically access and update document 
content, structure, and style. See, e.g., World Wide Web 
Consortium, 1998, Document Object Model (DOM) Level 1 
Specification, Version 1.0. The XML Pointer Language 
(XPointer) is designed for reference to elements, character 
strings, and other parts of XML documents. See, e.g., World 
Wide Web Consortium, 1998, XML Pointer Language 
(Xpointer). 

Accordingly, it is also important that browser functional- 
ity embedded in the application context be adaptable to 
HTML, XML and other markup languages being developed. 

Citation of a reference herein, or throughout this 
specification, is not to be construed as an admission that 
such reference is prior art to the Applicant's invention of the 
matter subsequently claimed. 

SUMMARY OF THE INVENTION 
General objects of the present invention are to provide 
methods and apparatus which overcome the above identified 
requirement and lacks in the current art. 

Specific objects of the present invention include methods 
and apparatus providing configurable markup language 
browser functionality embedded in the context of a client- 
server application running on standard end-user devices. 
The browser functionality of this invention is configurable 
so that the network resources accessible by a user are 
restricted in order to focus the user's attention to pre- 
determined relevant content. Such configuration may also be 
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used to block possibly offensive documents. Further, the 
browser functionality is configurable so that certain users are 
prevented for utilizing certain browser features. The browser 
configuration and allowed network access are separately 
customizable for each user. This invention is applicable both s 
to HTML and XML documents and also to documents 
formatted in emerging markup languages. 

Accordingly, this invention includes methods and appa- 
ratus for browsing markup language documents from within 
the context of an executing application. This is achieved by 10 
embedded browser functionality that can be activated to 
display an embedded browser sub-window inside the main 
application window. While the prior art provides the same 
resource access rights and browser interface functions to all 
users, the present invention provides methods and apparatus 15 
where some users are allowed to access any resource on the 
public Internet or private intranets, while other users can 
only access the limited lists of resources set forth in the 
content of their user profile. Further, the functionality and 
appearance of the user interface of the embedded browser 2Q 
sub-window is also configured from information in the user 
profile. The administrator of the system in which an appli- 
cation according to this invention is installed can change the 
resource access and browsing function privileges of users by 
editing the content of their user profiles. 25 

Network resource access is restricted by preventing the 
embedded browser functionality from generating linking 
information that is not allowed. In a preferred embodiment, 
a user with restricted Web browsing privileges is not pre- 
sented any location field in the browser sub-window, into 30 
which URIs that are not allowed can be entered by the user. 
Also, in the preferred embodiment, if an allowed document 
is delivered from its server with links to other documents 
that are not allowed, these links are filtered from the 
document before it is displayed in the browser sub-window. 35 
Therefore, a restricted user can not access documents that 
are not allowed by activating displayed linking information. 
Such a user can access network resources only by allowed 
links present in displayed and filtered markup language 
documents. Optionally, the browser dynamically creates a 40 
personalized user home page listing all links allowed to the 
user. 

Filtering methods are described for HTML and for XML, 
These methods can also be applied to other emerging 
markup languages, such as those being developed for con- 45 
sumer appliances. Preferably, the application is imple- 
mented in Java. If so, optionally, it can be an applet 
downloaded and executed in commercially available 
markup language browsers. 

In a first embodiment this invention includes an apparatus 50 
for a user to browse markup language documents, the 
documents being stored for retrieval at one or more com- 
puter systems attached to a network and containing linking 
information representing resource addresses, the apparatus 
comprising: an end-user device comprising processor, 55 
memory, network attachment, and display, wherein the 
memory stores user profile records whose contents describe 
the characteristics and preferences of the user, an application 
program comprising (i) instructions for causing the proces- 
sor to perform an application function which displays an 60 
application window including application specific controls 
and data, wherein the application specific controls are 
responsive to the content of the user profile records and 
comprise a browser control, and (ii) instructions for causing 
the processor to perform, responsive to user activation of the 65 
browser control, a browser function which displays within 
the application window a browser sub-window including 



browser specific controls and markup language documents, 
wherein both the displayed browser specific controls and 
any linking information retained present in the displayed 
markup language documents are responsive to the content of 
the user profile records. 

In a first aspect of the first embodiment, this invention 
includes the apparatus of the first embodiment wherein the 
browser specific controls comprise a location entry field for 
entry of linking information representing resource 
addresses, and wherein display or not of the location entry 
field is responsive to the contents of the user profile records. 

In a second embodiment, this invention includes a method 
for a user to browse markup language documents at an 
end-user device, the documents being stored for retrieval at 
one or more computer systems attached to a network and 
containing linking information representing resource 
addresses, the method comprising: entering user identifica- 
tion information, authenticating entered user identification 
information and loading user profile records associated with 
the authenticated user to the end-user device, displaying an 
application window at the end-user device including appli- 
cation specific controls and data, wherein the application 
specific controls are responsive to the content of the user 
profile records and comprise a browser control, displaying, 
within the application window and responsively to user 
activation of the browser control, a browser sub-window 
including browser specific controls and markup language 
documents, wherein both the displayed browser specific 
controls and any linking information retained in the dis- 
played markup language documents are responsive to the 
content of the user profile records. 

BRIEF DESCRIPTION OF THE DRAWING 
Other objects, features and advantages of the present 
invention will become apparent upon perusal of the follow- 
ing detailed description when taken in conjunction with the 
appended drawing wherein: 

FIGS. 1A-B illustrates an exemplary client-server archi- 
tecture and end-user device to which this invention is 
applicable; 

FIG. 2 illustrates an exemplary forest of representative 
tree-structured URIs; 

FIG. 3 illustrates a graphical interface of an application 
with embedded browser functionality presented to a user of 
a certain higher authority according to this invention; 

FIG. 4 illustrates a graphical interface of an application 
with embedded browser functionality presented to a user of 
a different lower authority according to this invention; 

FIG. 5 illustrates a method for filtering an HTML docu- 
ment by deleting linking information that is not allowed; 

FIG. 6 illustrates a method for filtering an XML document 
by deleting linking information that is not allowed; and 

FIG. 7 illustrates a graphical interface of a signed applet 
or a policy-based authorized applet with an embedded 
browser running inside a commercial browser program. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 
In the following, in section 1, an exemplary client-server 
system architecture, to which the methods and apparatus of 
the present invention are advantageously applied, is first 
described. Next, in section 2, detailed descriptions of the 
browser functionality of the present invention and its imple- 
mentation are presented. Finally, in section 3, methods for 
filtering markup language documents are described Where 
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necessary, the detailed description also includes concise 
discussions of necessary technical background. 
1. Client-server System 

I. 1. Architecture Overview 
FIG. 1A illustrates an exemplary 3-tier client-server archi- 
tecture applied to computerized medical records (CPR) 
distribution. This architecture is based jointly on a distrib- 
uted object architecture in which Common Object Request 
Broker Architecture (CORBA) compliant object request 
brokers (ORB) communicate using Internet Inter-ORB Pro- 
tocol (HOP) to connect and on markup language document 
transfer from servers to clients using the Hypertext Transfer 
Protocol (HTTP). The network illustrates is preferably the 
public Internet or private intranets. The CORBA family of 
distributed object standards are developed and published by 
the Object Management Group. The HTTP and related 
internet protocols are developed and published by the Inter- 
net Engineering Task Force. 

This client-server system of this figure, which is described 
in this subsection, is exemplary, being used for concreteness 
and ease of the subsequent description. The system and 
architecture is not to be understood as limiting, since the 
methods and apparatus of this invention are equally appli- 
cable to other client-server architectures, such as 2-tier 
client-server architectures, as well as to client-server archi- 
tectures not based on CORBA. For example, if the illus- 
trated business server objects and the front-end clients are all 
implemented in Java then Sun Microsystems' Remote 
Method Invocation (RMI) technology can be used instead of 
the CORBA architecture. Alternatively the Distributed Com- 
ponent Object Model (DCOM) of the Microsoft Corp. can 
be used in place of CORBA. 

Further, this exemplary architecture is applied, again for 
purposes of concreteness and ease of description only, to the 
distribution of computerized medical records for physicians, 
patients, and other users. This application is also to be 
understood as not being limiting, since one of ordinary skill 
in the art will appreciate how to adapt this invention to other 
application fields. Accordingly, the present invention 
encompasses not only application to CPR distribution, but to 
other vertical market domains and their applications, such as 
banking, insurance, airlines, hotels, transportation, and so 
forth. 

With reference again to FIG. 1A, the first tier of the three 
tier system is illustrated to comprise end-user devices 10 and 

II, which in turn comprise, at least, a processor, static and 
dynamic memory, a display, input means, and a communi- 
cation interface. The end-user devices can be standard PCS, 
such as desktop, workstation or notebook machines. They 
can equally be Internet appliances, such as WebTVs, screen- 
telephones, PDAs, etc., or even other types of information 
appliances with communication capabilities. 

The end-user devices run front-end client software includ- 
ing an application providing visual display of business data, 
markup language documents, and other resources available 
across the public Internet or private intranets. A user inter- 
acts with the user interface on the display of the end-user 
device presented by the client application software to send 
or request information from network-connected, tier-2 
server systems. 

Preferably, the application software is structured in a 
distributed object-oriented manner, so that, for example, the 
business data appears as business server objects 19. Also it 
is preferable that distributed objects be structured as 
CORBA-compliant client objects that interact with distrib- 
uted CORBA-compliant server objects. CORBA clients and 
servers, using ORBs resident on their end-user devices or 
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computers, communicate using HOP over exemplary net- 
work links 12. Client objects include stubs generated using 
CORBA's Interface Definition Language (IDL) in order to 
remotely invoke methods on the distributed server objects. 
5 Finally, this software is also preferably implemented in the 
Java language in a platform-independent manner and install- 
able as either a complete application or as an applet down- 
loadable from a markup language document server for use in 
a browser. 

10 According to this invention, the application software also 
includes markup language document browser functionality. 
Such browser functionality preferably acts as a client using 
the HTTP protocol to request markup language documents 
from servers over exemplary network links 13. The browser 

15 functionality then displays the received documents as 
instructed by the formatting markups in the documents. 
Secure HTTP (s-HTTP) is preferably used where secure 
HTTP connections are desired. The secure socket layer 
(SSL) protocol can also provide security at the socket layer 

20 for HOP communication. The system illustrated in FIG. 1A 
allows both browser/HTTP and ORB/HOP requests and 
responses to flow on the same network. 

The middle tier, or tier 2, of the three tier client-server 
architecture is illustrated to include markup language docu- 

25 ment server systems 14 and business server object systems 
18. Document server systems 14 are illustrated as running 
HTTP document server function 15, which responds to 
requests from HTTP clients, and provides, among other 
resources, HTML, XML, or other markup language docu- 

30 ments from document store 16, and Java applets from applet 
store 17. Applets according to the HTML and XML markup 
languages are referenced with the <APPLET> tag. One or 
more HTTP document server functions and associated stores 
can be resident on one or more HTTP server systems, and 

35 can be physically located anywhere on the network. 

Business server systems 18 are illustrated as running 
CORBA-compliant business-server objects 19, which indi- 
vidually respond to remote method invocations for specific 
type of data from client objects, which in turn are part of the 

40 application software running in the end-user devices. The 
CORBA-compliant business-server objects implement basic 
business logic of the business application of the client-server 
architecture, and thereby provide a dynamically generated 
and integrated view of the different tier-3 data servers. 

45 Illustrated in FIG. 1A are separate business server objects for 
particular classes of data stored in the client-server archi- 
tecture; alternately, one business-server object can respond 
to requests for more than one type of data. The business 
server objects can run in the same system process, in 

50 different system processes, on the same computer system, or 
on different computer systems. Although illustrated as resi- 
dent on separate system 14 and 18, alternatively HTTP 
servers and CORBA servers can also be co-resident on the 
same computer system. 

55 The third tier, or tier 3, is illustrated to include one or 
more data-server systems 20 communicating with business- 
server object systems 18 over exemplary network links 21. 
These data-server systems run data-server objects that 
present a CORBA-compliant object-oriented interface for 

60 the various classes of data stored on these systems. Data 
server objects can include existing non-object-oriented 
legacy data stores and applications that have been interfaced 
using CORBA-compliant IDL, i.e., "CORBA-wrapped" 
legacy systems. See, e.g., Orfali et al., 1997, Client/Server 

65 Programming with Java and CORBA, ISBN 0-471-16351-1, 
John Wiley & Sons, 1997 (a CORBA and Java reference). 
Alternatively, these data-server objects can be initially 
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designed in an object-oriented fashion with CORBA- 
compliant interfaces. Such systems do not need to be 
CORBA-wrapped. 

For concreteness, FIG. 1A illustrates an exemplary appli- 
cation of this three-tier client-server architecture to comput- 
erized patient record (CPR) distribution. Accordingly, sec- 
ond tier business-server objects and corresponding third tier 
data-server objects are illustrated for data types such as 
medical reports, medical images, lab results, and other types 
of medical data. Other appropriate business server objects 
not illustrated can provide general system functions such as 
session management, medical event notification, system 
security, display personalization, paging notification, 
patient-list retrieval, bookmarking, patient arrival and 
discharge, patient demographics, message exchange, data- 
base connection management, and so forth. 

1.2. The End-user Device 

The application software with the embedded browser 
functionality according to this invention runs on program- 
mable end-user devices with network communication capa- 
bilities. These can range from specialized information appli- 
ances to standard PCs, as known in the art. 

As illustrated in FIG. IB, these devices preferably 
include, at least, the following common structures known in 
the art: microprocessor 101, long-term ROM memory 103, 
dynamic RAM memory 102, display interface and display 
105, communication interface 104, input interface and 
means 107, and interconnect 106. Long-term memory can 
also include magnetic and optical devices. The display can 
be, for example, an LCD with an LCD controller. The input 
means can be such known devices as a keyboard, mouse, 
touch screen, buttons, voice recognition, and so forth, 
together with needed interface elements. These interconnect 
can be an external bus, or alternatively, when one or more of 
the illustrated structures are implemented together on a 
single VLSI chip, the interconnect can be a specialized 
on-chip interconnect along with an optional external bus. 

1.3. System Administration Databases 

The client application software of this invention, and 
especially its embedded browser functionality, which runs in 
the end-user devices, is configured according to data 
descriptive of the users of the system, in particular of their 
authorizations and access rights. In a preferred embodiment, 
this user-descriptive data is stored in data stores associated 
with the tier-2 server systems, in particular in user directory 
database 22 and user profile database 23. Although these 
databases are illustrated in FIG. 1A as being connected to 
object server system 18, they are preferably connected to 
whatever tier-2 server systems has need of the stored data. 
These data stores are described in this subsection. 

User directory 22 preferably stores for each user authen- 
tication information, role information, access control 
information, general information, and so forth. Authentica- 
tion information includes data used to identify a user as 
authorized to access the client-server system at all. This data 
can include user name and password, or biometric data, such 
as fingerprint, or so forth. Role information includes data 
indicative of a user's role in the institution using the client- 
server system. This data can indicate, for example, that a 
user is a physician along with speciality and seniority, or a 
nurse along with speciality and seniority, or a patient, or a 
legal guardian of a patient, and so forth. Access control 
information includes data indicative of a user's authority to 
access and update the various types of data stored through 
the system. For example, a system administrator is autho- 
rized to read and update the user directory and user profile 
databases. General user information can include such data as 
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office or ward location, phone number, application person- 
alization preferences, and so forth. The user directory can be 
implemented and accessed by commercially available direc- 
tory software known in the art, such as that implementing 

5 the Lightweight Directory Access Protocol (LDAP). LDAP 
is a widely used protocol for accessing, for example, an 
X.500 directory server, a Novel directory server, a Netscape 
directory server, and so forth. 

User profile database 23 stores information for configur- 

10 ing the embedded browser functionality present in the client 
application software of this invention. Browser 
functionality, especially the network access rights allowed to 
different users is typically decided by the administration of 
the client-server system in order to promote focused and 

15 productive use of the application. For example for a CPR 
application, physician users may be allowed unrestricted 
network access in order to search for medical information 
anywhere on the public Internet from within the context of 
the CPR client application. On the other hand, nurse users 

20 may be limited only to particular nursing related documents 
available on the group's or hospital's own intranet. Finally, 
patients may be even more limited to access only certain 
educational documents relating to their particular diagnoses. 
Code obfuscation or encryption techniques may be used to 

25 prevent tampering with downloaded user profile informa- 

Accordingly, FIG. 1A illustrates system administration 
graphical user interface (GUI) 25, for example provided on 
an administration workstation, by which a system 

30 administrator, or other designated user, enters and updates 
the contents of the user profile database 23 in accord with the 
functionality allowed to the various users. The same system 
administrator would typically also similarly enter and update 
user directory 22. 

35 In a preferred embodiment, the user profile database 
includes at least the following types of information for each 
user. First, there is included an indication of whether the user 
has unrestricted or restricted network access from the 
embedded browser functionality. Second, if the user has 

40 restricted network access, then the user profile includes 
representations of all the linking information addressing of 
all the network resources allowed to the user. Preferably, the 
linking information is in the format of universal resource 
identifiers (URI), and the user profile then has representa- 

45 tions of the URIs of all allowed markup language docu- 
ments. Herein, "linking information" is used to identify 
network resource addressing information of all types and 
formats. Third, the user profile preferably also includes 
indications of which other configurable aspects of browser 

50 functionality, such as the browser controls displayed to the 
user, support for markup language document forms, tables, 
and frames, applets, document printing, cookies, 
multithreading, and so forth, are allowed to the user. 
Although illustrated as two separate databases, in alter- 

55 nate implementations user directory database 22 and user 
profile database 23 may be stored together in a single 
database. 

In addition to control of embedded browser functionality, 
a separate and independent control prevents unauthorized 

60 access of a user to the business-server objects. Requests 
from the client applications to the business-server objects 
are intercepted by access decision facility 26, which checks 
whether the requesting user, who has the particular access 
control information stored in the user directory, is authorized 

65 to access the information requested in view of the access 
control policies stored in access control policy database 24. 
If the access control policies grant access, the server is 
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allowed to respond with the requested information to the 
client application. Otherwise, access is denied, and, for 
example, the service denial is logged to a log file for security 
audit purposes. 

1.4. Representation of Allowed URI List 

In the preferred embodiment, the user profile records for 
a user a representation of the URIs of all allowed network 
resources, such as markup language documents. The 
allowed URIs are selected from the typically large number 
of all possible URIs that can be accessed by the user. The set 
of all possible URIs can generally be structured as a tree, or 
as a forest of trees, or, generally, as a directed graph of linked 
URIs. Therefore, the allowed URIs are a sub-tree, a sub- 
forest, or a sub-graph of all possible URIs. Any represen- 
tations of sub-trees, sub-forests, or sub-graphs, as 
appropriate, that are known and apparent to one of ordinary 
skill in the arts can be advantageously applied to represent 
all allowed URIs in the user profile database. In this 
subsection, a preferred such representation of all allowed 
URIs is described with reference to FIG. 2, which illustrates 
an exemplary forest of three trees of possible URIs. 

In FIG. 2, nodes A, D, and J represent root URIs for the 
homes pages of Organization-1, Organization-2, and 
Organization-3, respectively. Children of a parent node 
extend the parent URI by one additional relative address. For 
example, child node G extends the URI of parent node D 
with the additional relative address of "TR/". Likewise, 
child node I extends the URI of parent node G with the 
additional relative address of WD-xlink. The list of all 
possible URIs is illustrated on the left in FIG. 2. Of these, 
this particular user is authorized to access all URIs except 
those for the nodes A, E, and H, which are indicated by 
arrow in the illustrated list and by arrowheads in the tree 
diagrams. 

Apreferred representation of the allowed URIs for storage 
in this user's profile is illustrated on the right in FIG. 2. In 
this representation, all URIs are the respective absolute 
addresses of allowed nodes. A URI followed the character 
"*" indicates that both the node having this URI address and 
all its child nodes are allowed. Nodes C, F and J are 
examples of allowed nodes for which all child nodes are 
allowed, and which accordingly have a "*" after their 
address in the allowed list. This representation is consider- 
ably more compact than the alternative in which the URI of 
every allowed node is individually listed. Note that it is 
possible to limit the granularity of allowed content. For 
example, in FIG. 2, although the home page for 
Organization-1, node A, is not allowed, children of the home 
page are allowed. 

In an alternative representation, the URIs listed are the 
absolute addresses of nodes that are not allowed. Here also, 
a special character can be used to indicate that a node and all 
its child nodes are not allowed. This alternative representa- 
tion is preferable in the case where a user is allowed to 
access most resources, only a few resources not being 
allowed. Such a case may occur, for example, if it desired to 
filter offensive or inappropriate information from appearing 
in the context of the client application program. 

Both representations may be combined in a single user 
profile database by including an indication of which repre- 
sentation applies to a particular user or to a particular group 
of URIs in the list for a particular user. The subsequently 
described markup document filtering methods work with 
either representation. 

1.5. Absolute and Relative URIs 

Since absolute and relative URIs are commonly used in 
the linking information present in markup language 
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documents, the following is a brief description the two types 
of URIs. Generally, an absolute URI is a full and complete 
address for identifying a document or resource in a network, 
such as an intranet or the public Internet. A relative URI is 

5 only a part of an address which extends a given absolute 
address with additional qualifications. 

First, in the case of the HTML markup language, specifi- 
cally in version 3.2, consider an exemplary home page for 
Organization-2 having the URI of http://www.org2.org/. 

10 Suppose that another directory, TR/, holds all technical 
reports of Organization-2. Then, with HTML 3.2 a relative 
link from the home page to the TR/directory can be repre- 
sented by the following linking information: 

15 <a href="TR/">Technical Reports</a> 

When a user activates this linking information, represented 
by the words "Technical Reports" displayed on the home- 
page with characteristic formatting, the linking information 
is resolved to the absolute URI address, namely http:// 

20 www.w3.org/TR/. This resolution is accomplished by con- 
catenating the contents of the relative linking information to 
the absolute address of the document displaying the relative 
linking information. 
The HTML 3.2 anchor tag also allows a link to point to 

25 specific sections, or locations, within a document. These 
sections or locations are known as document fragments. For 
example suppose the file home.html at URI address http:// 
www.org2.org/home.html has five sections, and a link spe- 
cifically to Section 4, and not to the start, or top, of 

30 home.html is desired. First, Section 4 is specifically identi- 
fied in the document by placing an anchor at the start Section 
4 with, for example, the following syntax: 

<a NAME-"section4"><h2>Section 4</h2x/a> 

35 Herein, "#section4" is called a fragment identifier. Then, 
Section 4 in home.html can be specifically and directly 
addressed in another document with the absolute URI 
including the fragment identifier: 

40 http://www.org2.org/home.hlml#section4 

In the home.html document, Section 4 can be specifically 
and directly addressed with the following relative URI 
including the fragment identifier: 

45 

Click here <a href="home.html#section4">Section4</a> to go to 

With these links, a user does not need to scroll from the start 
of home.html to get to Section 4. 

50 The methods of this invention do not distinguish between 
fragments of the same document, because, a reference to the 
start of a document or to any of its fragments causes 
download of the complete document. Therefore, a user can 
scroll to any other part of that document following access of 

55 a link to any fragment of that document. Thus, when an 
absolute URI is resolved from a relative URI in linking 
information found, fragment identifiers (e.g., #section4) are 
deleted, or ignored, before comparison to the allowed URI 
list. If the comparison shows that the URI is allowed, then 

60 the fragment identifier part in the filtered documents is used 
to access the desired location within the document. 

Accordingly, the allowed URI list need not maintain 
representation of allowed fragment identifiers. In other 
words, access granularity according to this invention is at the 

65 level of the document. 

The XML markup language also uses absolute and rela- 
tive linking information, including absolute and relative 
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URIs. XPointer defined elements can also be used in con- 
junction with the URI structure, as fragment identifiers or 
queries, to specify a more precise location inside a docu- 
ment. 

2. Browser Functionality 5 

This invention provides in a client application context and 
within the client application window a browser sub-window 
with browser functionality configurable in response to user 
profile parameters. Relevant user profile parameters are 
obtained for the client application when the user is first 10 
authenticated for client-server system access. In particular, 
the allowed URIs that can be accessed by a user are 
controlled by the user profile parameters. The client appli- 
cation interface itself is also preferably personalized accord- 
ing to the preferences and assignments of each user. 15 

The browser sub-window inside the application window 
preferably has a basic subset of the browser functionalities 
present in a standard markup language document browser 
program. For example, it is advantageous that at least basic 
navigation functions, represented by icons such as back, 20 
forward, reload, stop, and home, are allowed for all users. 
Basic search and bookmark functionality is also preferable. 
However, other features of browsers are preferably enabled 
or disabled for different categories of users. These config- 
urable features include support for markup language forms, 25 
tables, applets, frames, and so forth, document printing, 
server cookies, task multithreading, and so forth. Generally, 
browser functionality can be configured in several manners 
in order to meet the requirements of several categories of 
users. 30 

Importantly, the browser functionality of this invention 
also has support for limiting allowed linking information, or 
URIs, that can be accessed by a user. The browser function- 
ality achieves this limitation by preventing a user from ever 
sending a request to a HTTP server that is not allowed. In a 35 
preferred embodiment, the browser functionality both 
removes any editable field for entry of URIs to be accessed, 
and also removes unauthorized linking information from 
markup language documents before their display. To remove 
unauthorized linking information before display, all markup 40 
language documents are intercepted, their contents parsed, 
and the parsed contents filtered to find and delete linking 
information that is indicated as not allowed in the user 
profile. 

For example, in the exemplary CPR system, a physician 45 
has relatively unrestricted network access, and the browser 
sub-window presents both an editable location entry field 
and bypasses filtering of markup language documents. On 
the other hand, a patient has relatively restricted access, and 
any location field is either removed or made not editable for 50 
entry of URIs, and Unking information in markup language 
documents is filtered in view of the user profile. 

In the following subsections, details of the application 
interface and its use are presented, first, for the case of 
unrestricted network access, and, second, for the case of 55 
restricted network access. The last subsection presents a 
preferred implementation of the application program and 
embedded browser functionality. 
2.1. Unrestricted Browser Interface 

The graphical user interface (GUI) of a client application 60 
with embedded browser functionality of this invention can 
take a wide variety of layouts and arrangement, each adapted 
to the needs of the particular client application and the 
preferences of users. In a preferred embodiment independent 
of the layout and arrangement, the client application typi- 65 
cally displays, according to a windowing paradigm, appli- 
cation specific data and application specific control, and 



also, when the browser functionality is activated, also 
browser specific data and browser specific controls. Appli- 
cation specific data is, of course, the substantive data rel- 
evant to the application, for example, medical records infor- 
mation for the exemplary CPR application. Application 
specific controls provide facilities for controlling application 
functioning, and, also in the preferred embodiment, include 
display regions selectable with a pointing device or a 
keyboard in order to activate particular application func- 
tions. Such display regions can include menu bars, tool bars, 
icons, buttons, dialog boxes, and so forth as known to one 
of ordinary skill in the art. Browser specific data typically 
includes markup language documents formatted and dis- 
played according to their included markup instructions. 
Browser specific control are, similar to the application 
specific controls, activated in order to control browser 
functioning. 

The display of these controls and data can be laid out and 
arranged in many manners in different windowing para- 
digms. In preferred embodiments, the application specific 
controls and data will be spatially separated and displayed in 
a main application window. The browser specific controls 
and data will be similarly spatially separated in a browser 
sub-window. These various display elements can be resized, 
rearranged, temporarily hidden, and so forth; windows can 
be tiled, cascaded, overlapped, minimized, maximized, and 
so forth; all as is known in the art. This invention encom- 
passes all these well-known windowing layouts and arraign- 
ments. 

Without limitation, FIG. 3 illustrates one exemplary lay- 
out and arrangement of the GUI of this invention appropriate 
for simultaneous display of the display elements of the 
preferred GUI. In this figure, window 30 is the client 
application main window configured for a less restricted 
user, such as a physician. Horizontal toolbar 31 preferably 
displays application specific controls that are generic to most 
application sub-functions. Illustrated in this toolbar are, for 
example, controls for Patient-List display, Tools selection, 
Help request, and browser toggle 37. The Browser toggle 
control activates and deactivates the embedded browser 
functionality. Vertical toolbar 32 preferably displays further 
application specific controls that are specific to a current 
application sub-function. Illustrated here are controls 
requesting various sections of the CPR of a patient already 
selected from a previously displayed patient list. Contents of 
the requested CPR sections, the application specific data in 
this example, are then displayed in report 33, which pref- 
erably can be adjusted in size. 

In FIG. 3, the browser functionality is activated and 
browser sub-window 34 is intermediately sized within the 
application window. The browser sub-window includes tool- 
bar 35, displaying browser specific controls, and sub- 
window 36, displaying browser specific data, namely a 
retrieved markup language document. Because the physician 
user here has unrestricted network access, the browser 
specific controls include editable location entry field 38 for 
the free entry of URIs to access. 

This windowing interface is accessed according to the 
following steps, which result in the information display 
illustrated in FIG. 3. 

1. (login) Upon first invoking the CPR application pro- 
gram at an end-user device, a login screen appears 
where the user enters authenticating information, for 
example a user ID and password, or presents biometric 
information, such as a scanned fingerprint. 

2. (authentication) The application then authenticates the 
user and the user's access rights by, for example, 
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invoking authentication methods on tier 2 servers tion field is not present in the browser specific control 

which access information in the user directory and toolbar included in browser sub-window 43. Alternately, a 

compare it to entered authenticating information. After current location field may be displayed that is disabled for 

authentication, user profile records are loaded to the entr y of linking information. Also since markup language 

memory of the end-user device. 5 documents are filtered before display, only allowed linking 

3. (application interaction) The application then displays information, as indicated in the user profile, is displayed for 
application window 30 configured according to direc- user activation in markup language documents. 

tions in the loaded user profile records and the user steps for accessing the user interface and displayed 

commences application interaction with the application information illustrated in FIG. 4 are the similar as those 

specific controls. For example, the user then obtains a 10 described with reference to FIG. 3, namely the steps of 

patient fast by activating the patient-List control, selects logiD; authentication, application interaction, browser 

a patient from the list, and then selects a section of CPR activ atio n> browser interaction, and logoff. Any differences 

of that patient by activating the desired report control are clear limitations due t0 the greater access restrictions 

The contents of the desired section are then displayed placed on this user 

in report sub-window 33. „ 2 21 Home Page for Restricted Users 

4. (browser activation) When network access is needed in In an alternative embodiment, network access for 
the context of the client application, the user starts the restricted users makes explicit use of the allowed URIs 
embedded browser functionality by activating browser represented in the user profile records. In one such 
toggle control 37. For example, this control displays alternative, the browser presents specific controls enabling 
"Open Browser" when the browser is inactive, and 20 user selection of any allowed URIs. Such specific controls 
"Close Browser" when active. can be a drop -down selection list structured either as hier- 

5. (browser interaction) The activated browser function- archical tree-structured bookmarks representing the allowed 
ality displays resizeable browser sub-window 34, URIs, or more simply menus listing all allowed URIs for 
including browser specific controls 35 and sub-window selection. In another alternative, the browser dynamically 
36 for browser specific data. Because the user profile 2 5 creates and displays, either upon initial activation or upon 
records indicate unrestricted access, the browser spe- user request, a personalized markup language document, a 
cific controls include editable location entry field 38, user "home page", which includes linking information rep- 
and the markup language documents displayed in sub- resenting all allowed URIs, so that the user may access a 
window 36, for example, a document initially resource by activating its linking information. This home 
displayed, are not filtered, having intact linking infor- 30 page can be formatted according to either HTML or XML 
mation. Accordingly, the user can interact with the syntax. 

application browser functionality in a substantially l n this alternative embodiment, both the URI itself along 

standard manner by entering URI address in location with text descriptive of the addressed resource can be 

field 38, or activating linking information in displayed presented to the user. Preferably, the descriptive text is the 

documents. 35 title of the addressed document. A "crawler" program, as 

6. (logoff) When finished, the user logs out of the known in the art, can periodically access each allowed URI 
application, which closes application main window 30. address on the network to retrieve the document title, or 

2.2. Restricted Browser Interface other descriptive text, and to store it along with the allowed 

Importantly, according to the present invention, the spe- URI. Additionally, the crawler program can also check if 

cific controls and data are actually displayed in the appli- 40 allowed URIs are current and reachable, 

cation window in a manner responsive to a user's authorities This alternative is further described with reference to FIG. 

and preferences indicated that user's profile records. For 2. If the user's only allowed URIs are those for node J and 

example, access to certain application functions can be all its children, a dynamically created home page need only 

prevented for unauthorized users by not displaying the display linking information representative of the URI http:// 

controls by which they can be activated. Browser function- 45 www.org3.com, along with optional descriptive text. If the 

ality is similarly configured in a preferred embodiment user can access all the allowed nodes of FIG. 2, then the list 

according to a user's indicated authorizations by displaying of allowed URIs has seven parent URI entries, and a 

only controls for those functions for which that user is dynamically created home page includes linking informa- 

authorized. If a user's network access is restricted, the tion representative of these seven URIs, along with optional 

browser sub-window does not display an editable location 50 descriptive text. 

entry field and unauthorized linking information is filtered The browser functionality of the application is modified to 

from markup language documents before display. include instructions to access the profile of a restricted user 

For the exemplary CPR application, FIG. 4 illustrates and its stored allowed URI list to dynamically create such a 
exemplary application main window 40, which is similar to home page or browser specific controls, 
main window 30 of FIG. 3 except that it is configured for a 55 2.3. Application/Browser Implementation 
user of more restricted authority and access, such as a The application, and its browser functionality, are imple- 
patient. This window, like that in FIG. 3, is not limiting, but mented with encoding instructions and data placed in end- 
is exemplary of one layout and arrangement of the GUI of user device memory that together cause the end-user device 
the preferred embodiment of this invention. In FIG. 4, in processor, and the other end-user device components, to 
contrast with application window 30 of FIG. 3, generic 60 function according to this invention. Such instructions and 
application toolbar 41 does not display the Patient-List data resident in an end-user device are generally the means 
control, since a patient is permitted to view only that by which the methods and actions of the present invention 
patient's CPR. Also, CPR-display sub-function toolbar 42 are accomplished. In particular, the necessary data relevant 
does not display the Message control, since messages to this invention derives from the content of the user profile 
between care providers are considered to be private. 65 records and, additionally, of the user dictionary records. This 

The network access of this user being also indicated as content specifies user personalization, authorizations, 

restricted in the user's profile records, accordingly, a loca- allowed URIs, and so forth. The necessary instructions 
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include instructions encoding application function which 
format application specific controls in a manner responsive 
to the user profile data as described. They further include 
instructions encoding browser functionality responsive, in 
the manners described, to the content of the user profile 
records. 

The application instruction can first be implemented in 
any convenient programming language and then extended 
with the browser functionality of this invention in standard 
manners known to one of skill in the art. Preferred languages 
are object oriented in order that server objects, present in the 
preferred client-server architecture described, can be 
directly invoked. More preferred is use of the Java language, 
so that the resulting instructions are platform independent 
and executable in any Java-compatible environments, such 
as operating systems or markup language browsers with 
Java virtual machines. Such Java coded applications can be 
installed either as a standalone application or downloaded as 
an applet specified in a markup language document. 

In particular, the graphical user interface components of 
the application and its embedded browser functionality can 
be preferably specified with the Swing component set of the 
Java Foundation Classes (JFC) from Sun Microsystems. The 
Swing component set assists in specifying such windowing 
components as menus, tool bars, dialogs, and so forth, and 
extends the basic Abstract Windows Toolkit (AWT) of Java. 
This component set provides classes and application pro- 
gramming interfaces (API), for example, an HTML Editor 
Kit, the JEditorPane class, the JPanel class, and so forth, that 
can be directly used to implement the described browser 
functionality. See, e.g., The Swing Connection, http:// 
www.javasoft.com/products/jfc/tsc/index.html). 

Additionally, software components already providing 
complete portions of standard browser functionality can be 
imported into a client application and modified according to 
the present invention. For example, Sun's JavaHelp com- 
ponents use the Swing and other Java libraries to parse and 
display HTML 3.2 help documents. See, e.g., JavaHelp; a 
New Standard for Application Help and Online 
Documentation, http://www.javasoft.com/products/ 
javahelp/). ICEsoft's ICE Browser Java component can be 
embedded in applications to provide standard browsing 
functions in an application sub-window. These standard 
functions can then be extended and modified to provide the 
browser functionality of this invention. See, e.g., ICEsoft 
A/S, Bergen Norway, http://www.icesoft.no/products.html). 
Alternatively, the HoJava browser bean can be embedded 
and similarly modified and extended. This is a less prefer- 
able alternative because HoUava has a large initial size 
which would grow with needed modifications. 

Optionally, people with special needs can be accommo- 
dated with accessibility extensions to the browser function- 
ality which are advantageously based on Sun Microsystems' 
Accessibility API (Accessibility: Support for People with 
Disabilities, http://www.javasoft.com/products/jfc/ 
index.html#access). This API provides an interface by which 
technologies for meeting special needs can interact and 
communicate with Swing and Abstract Windows Toolkit 
(AWT) components. This API provides the necessary sup- 
port for accessibility technologies to locate and query user 
interface objects inside a Java application running in a Java 
virtual machine. Thus, it is possible to design the embedded 
browser functionality so that it interfaces with a speech 
recognition engine. The browser can also use the Accessi- 
bility API to interface with screen readers. 
3. Filtering Markup Language Documents 

As set forth above, restricting user network access to only 
allowed URIs is achieved, in part, by filtering linking 
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information that is not indicated as allowed in the user 
profile from displayed markup language documents. In this 
section filtering methods for HTML and XML documents 
are described. The type of a markup language document can 

S be easily determined from document type declarations in its 
header information. These filtering algorithms are preferably 
implemented to be tolerant of common markup language 
syntax errors including, at least, missing end tags. 

These algorithms involve parsing and string matching, 

10 and are advantageously implemented as separate modules in 
languages specialized for performing string matching, such 
as sed or perl. 

Alternatively, they can be implemented integrally with the 
browser functionality, preferably in Java. 

is 3.1. Filtering HTML Documents 

FIG. 5 illustrates the preferred method for filtering HTML 
documents. This invention also encompasses alternatives 
apparent to those of skill in the art in view of this figure and 
its accompanying description. 

20 First, embedded browser functionality 50 requests an 
HTML document from allowed HTML server 51. Upon 
return of the requested document, the contents of the user 
profile are checked at step 52 to determine if the user has 
unrestricted network access. If so, filtering is bypassed for 

25 the returned HTML document. If not, the users network 
access is restricted, and the returned document is filtered to 
delete linking information that is not allowed. 

Step 53, the first step in HTML document filtering, parses 
the returned document in order to locate all linking 

30 information, or linking elements. These elements are simply 
identified as those whose start-tag contains an href attribute 
identifying an addressed resource, such as a markup lan- 
guage document or part of a markup language document. 
Accordingly, this steps searches for all occurrences of the 

35 href attribute, which are recognized by the letters "href, 
followed by zero or more spaces, followed by the "=" 
character, followed by zero or more spaces, and finally 
followed by the "" character. All linking elements found are 
stored in a list for subsequent processing. 

40 Each link element found and stored in the list is selected 
for processing at step 55 until the list is found to be empty 
at step 54. When the list is empty, filtering is complete and 
the markup language document is returned for further pro- 
cessing by embedded browser functionality 50. 

45 Step 56 processes each link element. First, as previously 
described, each href attribute value is resolved to an absolute 
address, if the address is initially relative, by using the 
known absolute address of the current page in which the link 
element was found. Next, the representation of the allowed 

50 URIs from the user profile is searched for this resolved 
absolute address. The search ignores any fragment identifier 
part that may be present in the resolved absolute address. If 
no allowed URI in the list matches the absolute address, then 
the link is not allowed, and it is filtered out by deleting the 

55 start-tag and the corresponding end-tag of the element 
containing the href attribute from the HTML document. 
Examples of deleting links that are not allowed are presented 
in Appendix A. 

Parsing and string matching are performed in a case- 

60 independent manner since URIs and HTML tags are case- 
insensitive. 
3.2. XLink Overview 

Before describing the method of filtering XML 
documents, a brief summary of XML linking information, as 

65 defined by the XLink specification, is provided. One of skill 
in art will immediately appreciate how to adapt the methods 
presented to any future changes to the XLink specification. 



US 6,476,833 Bl 
17 18 

XLink linking elements are identified by the presence of First, embedded browser functionality 60 requests an 

the reserved xmhlink attribute. Each linking element has one XML document from allowed XML server 61. Upon return 

or more associated locators that identify the addresses of the of the requested document, the contents of the user profile 

remote resources participating in the link. In a locator the are checked at step 62 to determine it the user has unre- 

href attribute identifies the address of a resource, either as an 5 stricted network access. If so, filtering is bypassed for the 

absolute URI, or as relative address, i.e., a fragment iden- returned XML document. If not, the user's network access 

tifier (XPointer) relative to an absolute address, or both. ^ restricted, and the returned document is filtered to delete 

XML linking elements are either inline or out-of-line, and lin * in g information that is not allowed, 

also either simple or extended. In an inline link, the content u Ste P 63 > ih * ^ TSi ste P ln H ™L document filtering, parses 

of the linking element includes the associated locator serv- 10 [h ° ret " rned document in order to locate all linking 

ing to identify the address of the participating resource. A l nform f on ' ° r hnfan S ^^f, ™ d to store them m a ist 

simple inline link has only one locator and combines into a f° r subsequent processing. Linking elements are indicated 

. , . r .• . • . , b y tne xml:link attribute. This attribute may be explicitly 

single element the functions of a linkmg elemerU, a locator, , ^ a linkin element si as iUustrate / m th £ 

and a descriptor of resource attributes. The HTML anchor above examples> or it be indirectl mdicated ^ a 

element, <a . > is an example of a simple inline link, is default value in an attribute . list declaration of a linking 

Another example of an inline simple link is shown below: element For example> the a t tr ibute-list dec i aratio ns 

<P>The headquarters of <mySimpleLink xml:link="simple" <!ATTLIST mylink xml:!ink CD ATA #FTXED "simple"> 

^^TT^^^^ 3<I decIares that aU elements in the c ™ XML 

20 document are simple linking elements. Accordingly, all 

Here, mySimpleLink is a user-defined simple linking ele- attribute-list declarations as well as element start-tags are 

ment. Inline links can also be extended, containing multiple parsed in order to recognize all linking elements, 

locators addressing multiple resources. Each linking element found and stored in the list is 

An out-of-line link, in contrast, does not itself identify the selected for processing at step 65 until the list is found to be 

link's addressed resources, instead requiring one or more 25 empty at step 64. When the list is empty, filtering is complete 

associated, but separate, child, or dependent, addressing and the markup language document is returned for further 

elements that specify the addresses of linked resources. An processing by browser functionality 60. 

extended out-of-line link addresses many resources, sepa- Next, step 66 checks the inline attribute of each linking 

rating the identification of a link from the identification of element to determine if the linking element is inline or 

the addressed resources. The following is an example of an 30 out-of-line. The default value for the inline attribute is true, 

extended out-of-line link: For inline linking elements, step 67 finds, for simple inline 

links, the href attribute present, or, for extended inline links, 

<myExtendedLink xml:!ink="extended" inline-"false"> the href attributes present. For each found href attribute, step 

„■ „,„ . „, „ . , .... 68 resolves, if necessary, the address indicated in the href 

■docator href=' products.xml /> . , . ., ., , , 

35 attribute to an absolute URI address, searches the represen- 
<iocator href="service.xmry> tation of the allowed URIs for the indicated absolute address 

(minus any fragment identifier XPointer part), and deletes 
<locator href-"http : //ww.org4.com"/> the href attribute from the e l ement start tag if it is not 

</myExtendedLink> allowed. Steps 69 and 70 delete the linking element start tag 
40 and corresponding end tag from the document if all the 

Here, myExtendedlink is a user-defined extended out-of- contained href elements are not allowed and have been 

line linking element addressing three resources, two deleted from the start tag. 

expressed relative to the document in which the linking Processing out-of-line linking elements is similar except 

element is contained and the third expressed as an absolute that all child, or dependent, addressing elements which 

address. One way that an extended out-of-line link can be 45 specify the addresses of linked resources must first be found, 

used is that the user is provided with a menu list of links (for Accordingly, step 71 finds all such locator, group, and 

example, three in the example above) and can choose which document elements. For locator elements, step 72 finds its 

one to go to. Simple out-of-line links addressing only one href attribute, resolves this attribute to the absolute address 

linked resource are also possible. if necessary, checks the list of allowed URIs for the resolved 

Dependent addressing elements can be "locator" 50 absolute address, and deletes the locator element if the href 

elements, as in the above example. Dependent addressing attribute is not in the allowed URI list. Step 73 and 74 delete 

elements can also be a "group" of "document" elements, the out-of-line linking element's start tag and corresponding 

forming together an interlinked group. The "group" ele- end tag from the document if no locator elements remain in 

ments marking an extended link group which is a collection the start tag. 

of "document" elements that contain links to other 55 The processing of group and document addressing ele- 

documents, Each linked document in the group is identified ments is similar. Accordingly, step 71 finds all such locator 

by a associated "document" element. "Document" elements and document elements and notes the value of their href 

therefore also have href attributes specifying the addresses attribute. For locator elements step 72 resolves the href 

of linked resources. attribute to the absolute address if necessary, checks the list 

3.3. Filtering XML Documents 60 of allowed URIs for the resolved absolute address (minus 

FIG. 6 illustrates the preferred method for filtering XML any fragment identifier part), and deletes the corresponding 

documents. HTML and XML documents can be distin- locator element if the href attribute is not in the allowed URI 

guished by the document type declaration appearing at the list. Step 73 and 74 delete the out-of-line linking element's 

beginning of each markup language document. This inven- start tag and corresponding end tag from the document if no 

tion also encompasses alternatives apparent to those of skill 65 child locator elements remain for the out-of-line element, 

in the art in view of this figure and its accompanying The processing of extended link groups is similar. Group 

description. elements are found in step 63 by checking for xml:link 
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attribute values of "group". Step 71 finds all document 
elements of the extended link group and notes the value of 
their href attribute. For document elements step 72 resolves 
the href attribute to the absolute address if necessary, checks 
the list of allowed URIs for the resolved absolute address 5 
(minus any fragment identifier part), and deletes the corre- 
sponding document element if the href attribute is not in the 
allowed URI list. Step 73 and 74 delete the group element's 
start tag and corresponding end tag if no child document 
elements remain for the extended link group element. lQ 
3.4. Extension to Other Domains 

The filtering methods described in this section, and this 
invention generally, are not limited to only HTML and XML 
documents with linking information formatted as URIs, but 
can be generally applied to any markup language documents 
with a syntax providing identifiable markup elements serv- 15 
ing as linking elements indicating network addresses of 
accessible resources. One of skill in the art, in view of the 
previous description, will appreciate how to store lists of 
linking information in other formats, possibly compressed if 
appropriate, and how to modify the parsing steps in the 20 
described filtering methods to recognize linking element 
defined by other markup languages. 

In particular, these methods can be applied to markup 
languages being developed by the Advanced Television 
Systems Committee (ATSC) for the consumer electronics 25 
industry. See, e.g., Broadcast HTML Specification, http:// 
toocan.philabs.research.philips.com/misc/atcs/bhtml; 
Wugofski, 1998, a Modular Hypertext Markup Language for 
Broadcast Applications, Draft no. 4, Over the Moon 
Productions/Gateway. The ATSC is in the process of devel- 30 
oping application programming interfaces for a Digital 
Television Application Software Environment (DASE) com- 
pliant receiver, including markup languages which are simi- 
lar to HTML. 

For example, xHTML specifies a collection of document 35 
type definition (DTD) sets that can be combined to specify 
xHTML-based platforms, such as the w3HTML, bHTML, 
and cHTML platforms. The w3HTML platform provides 
support for full World Wide Web (WWW) connectivity. The 
cHTML platform provides a compact profile for appliance- 40 
oriented products. The bHTML platform provides a profile 
for TV-centric products written in XML, including HTML 
elements and attributes, and including new synchronization 
functionality as new elements, attributes, and style proper- 
ties. 45 

All these markup languages define linking elements with 
an href attribute indicating a URI specifying the address of 
a network resource. These Unking elements define links 
between a current element in a current document and the 
destination anchor in a destination document. 50 

In addition to accommodating the TV-type appliance 
applications above, the methods of this invention can also be 
generally applied in other consumer appliances. Generally, it 
is anticipated that browser functionality will become avail- 
able in standard consumer produces, for example, micro- 55 
wave ovens and other kitchen appliances, pagers and other 
specialized information appliances, and so forth. These 
appliances will be able to connect to Internet servers for 
product upgrades, feature upgrades, bug fixes, and so forth. 
This embedded browser functionality can advantageously 60 
use the methods and apparatus of this invention, along with 
a permanently stored list of allowed URIs, to limit Internet 
access of the consumer appliances to the specified portal 
servers, problem fix servers, upgrade servers, or so forth. 
Accordingly, these specific servers can be accessed for their 65 
specific functions by a single button and with no consumer 
skill required. 
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4. Running an Applet Versus an Application 

If the application, as well as its embedded browser 
functionality, is coded in the Java language, it can be 
installed in an end-user device either as a standalone appli- 
cation or as an applet downloaded and executed inside most 
commercially available markup language browser pro- 
grams. Installation as an applet, instead of an application, is 
advantageous in that the applet can be upgraded by merely 
placing a new version on a server machine, whereas appli- 
cation upgrade requires placing the new version on every 
end-user device. Further, applets provide easy installation 
for most end-user devices because browser programs are, or 
will be, widely available for almost all end-user devices. 
Applets do have the disadvantage of requiring download 
time. 

Use of a Java runtime plug-in permits a standard Java 
virtual machine environment for applets across the range of 
commercial markup language browsers. Such plug-in tech- 
nology is available from Sun Microsystems' (Java Plug-In, 
http://www.javasoft.com/products/plugin/). Further, applets 
can be marked as "signed" so that they are trusted to access 
local files and to open connections to network servers other 
than the one from which they were downloaded. Addition- 
ally security can be provided by local configuration code, 
which checks policy files, and, if appropriate, authorizes 
individual applet access to files or network addresses. 

FIG. 7 illustrates an exemplary and non-limiting arrange- 
ment and layout of the graphical user interface of this 
invention as presented by a signed applet being run by a 
commercial markup language browser. Here, window 80 is 
the commercial browser's standard window with its own 
toolbar 81. Inside this window, sub-window 82 presents the 
display generated by the applet of this invention. Here, 
similarly to FIG. 3, this is illustrated as the display for a less 
restricted physician-type user. Of course, for a more 
restricted patient-type user the display would be more simi- 
lar to FIG. 4. Browser toggle control 83 on the top right- 
hand corner of the applet sub-window activates or deacti- 
vates the browser functionality embedded in the applet 
application. Accordingly, browser sub-window 84 is in 
effect a browser in a browser. 

Use of an applet differs from use of an application only in 
that the user initially starts a commercial browser available 
on the end-user device and directs it to the URI of the HTML 
page referencing the signed Java applet. Such an applet 
reference is identified with an applet tag having a code 
attribute identifying the name of the applet class filename, 
and an optional "archive" attribute identifying a jar file in 
which the class is archived. 

Appendix A 

This appendix presents examples of deleting HTML links 
that are not allowed. In HTML 3.2 the anchor tag <a . . . > 
and the area tag <area . . . > are usually used with href 
attributes to specify linking information. For example, con- 
sider the following simple HTML source segment that uses 
the anchor tag: 

<P>The headquarters of <a href="http: 

//www.org3.com">Organization-3</a> are moving to Amster- 

A markup language browser will typically display this as: 

The headquarters of Organization- 3 are moving to Amsterdam. 

Clicking on the underlined word will direct the browser to 
download the document at the address http:// 
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www.org3.com. If this document is not allowed for a user, 
the HTML filtering methods, upon parsing the document, 
detect the start-tag containing the linking information 'href= 
"http://www.org3.com"' and the corresponding end-tag. 
Since this is not in the allowed URI list, these start and end 
tags are deleted, leaving the following in the filtered docu- 
ment: 

<P>The headquarters of Organization-3 are moving to Amster- 
dam.-^ 

Because the anchor tag is deleted, no link is displayed to the 
address that is not allowed. 

Image maps are another mechanism for specifying linking 
information. Consider the following HTML document frag- 
ment: 

<map name="bottom"> 

<area shape="rect" alt="Organization-3 Home Page" 

coords-"l, 1, 100, SO" 

href="http://www.org3.com/"x/area> 

<area shape="rect" alt="Welcome Page" 

coords="200, 300, 250, 350" href-"/welcome.html"x/area> 

<a href="index.map"ximg src="index.gif 
ISMAP="#bottom"x/a> 

Here a browser would display the image file, index.gif, with 
two hotspot rectangles, one in the upper left-hand corner and 
the other in the lower-right hand corner at the specified 
coordinates. The upper hotspot rectangle is a link to the 
Organization-3 home page, while the lower hotspot links to 
the welcome page in the same relative directory as the 
document fragment. If the Organization-3 home page is not 
allowed for the user, then the HTML filtering methods will 
detect and delete the area start-tag containing the attribute 
href="http://www.org3.com/" and the corresponding end- 
tag. The filtered document becomes: 

<map name="bottom"> 

<area shape="rect" alt="Welcome Page" 

coords="200, 300, 250, 350" href="/welcome.html"x/area> 

<a href="index.map"ximg src="index.giP' border=0 
ISMAP="#bottom"x/a> 

Display of this filtered HTML document presents only the 
lower hotspot linking to the welcome page in the same 
relative directory as the document fragment. 

All references cited herein are incorporated herein by 
reference in their entirety and for all purposes to the same 
extent as if each individual publication or patent or patent 
application was specifically and individually indicated to be 
incorporated by reference in its entirety for all purposes. 

What is claimed is: 

1. An apparatus for a user to browse markup language 
documents, the documents being stored for retrieval at one 
or more computer systems attached to a network and con- 
taining linking information representing addresses of net- 
work resources, the apparatus comprising: 
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an end-user device comprising processor, memory, net- 
work attachment, input means, and display, wherein the 
memory stores user profile records whose contents 
describe characteristics and preferences of the user 
5 relating to the user's restrictions to at least one of 
access to network resources and use of browser specific 
controls, and 
an application program comprising: 
(i) instructions for causing the processor to perform an 
10 application function which displays an application 

window including application specific controls and 
data, wherein the application specific controls are 
responsive to the content of the user profile records 
and comprise a browser control, and 
15 (ii) instructions for causing the processor to perform, 
responsive to user activation of the browser control, 
a browser function which displays within the appli- 
cation window a browser sub-window including 
browser specific controls and markup language 
20 documents, wherein both the displayed browser spe- 

cific controls and linking information retained in the 
displayed markup language documents are respon- 
sive to the content of the user profile records. 
2. The apparatus of claim 1 wherein the browser specific 
25 controls comprise a location entry field for user input of 
linking information representing resource addresses to be 
accessed, and wherein the browser function displays or not 
the location entry field responsively to contents of the user 
profile records. 

30 3. The apparatus of claim 1 wherein contents of the user 
profile records comprise an indication of allowed linking 
information, and wherein the browser function retains only 
allowed linking information in the displayed markup lan- 
guage documents, whereby the user can only access only 

35 allowed resources from a displayed markup language docu- 
ment. 

4. The apparatus of claim 3 wherein the browser function 
filters markup language documents in order to delete linking 
information that is not indicated as allowed by contents of 

40 the user profile records. 

5. The apparatus of claim 4 wherein the markup language 
documents comprise HTML documents, and wherein the 
browser function filters an HTML document by parsing the 
document to find href attributes, by locating linking infor- 

45 mation in found href attributes, by resolving addresses in 
located linking information to absolute addresses, and by 
deleting located linking information from the HTML docu- 
ment that is not indicated as allowed by contents of the user 
profile records. 

50 6. The apparatus of claim 4 wherein the markup language 
documents comprise XML documents, and wherein the 
browser function filters an XML document by parsing the 
document for XLink elements, by locating linking informa- 
tion from all href attributes associated with found XLink 

55 elements, by resolving addresses in located linking infor- 
mation to full address, and by deleting located linking 
information from the XML document that is not indicated as 
allowed by contents of the user profile records. 

7. The apparatus of claim 6 wherein the href attributes 

60 associated with an XLink element are either (i), if the XLink 
element has a simple type, located in the element start-tag, 
or (ii), if the XLink element has an extended type, located in 
locator and document element children of the XLink ele- 
ment. 

65 8. The apparatus of claim 3 wherein the indication of 
allowed linking information indicates only whether or not 
entire markup language documents are allowed. 
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9. The apparatus of claim 1 wherein the memory also parsing an HTML document to find href attributes, 
stores instructions (for interpreting Java codes, and wherein locating linking information from the found href 
the instructions of the application program comprise inter- attributes 

pretable Java codes. , . ' . 

10. The apparatus of claim 1 wherein user profile or user resolving addresses in located linking information to 
directory databases are resident on one or more network absolute addresses, and 

attached computer systems, and wherein the application deleting located linking information that is not indicated 

program further comprises instructions for downloading the as allowed by contents of the user profile records, 

user profile records from the user profile or user directory 2 0. The method of claim 18 wherein the markup language 

databases. .... documents comprise XML documents, and wherein the 

11. The apparatus o claim 1 further comprising business 10 fiherin XML markup language documents further com- 
data server systems which provide business data requested nr ises- 

by the end-user device. p '. 

12. The apparatus of claim 1, wherein the user profile parsing an XML document to find XLmk elements, 
records relate to the user's restrictions to access to network locating linking information from all href attributes asso- 
resources and use of browser specific controls. ciated with found XLink elements, 

13 The apparatus of claim 1 wherein said user profile 1 reso lving addresses in located linking information to 

records are created for each user but not by each user so that b j addresses> and 

each user does not have access to his or her user profile , ausumlc *""i«k*»> <"iu 

record and cannot alter his or her user profile record. deleting located linking information that is not indicated 

14. A method for a user to browse markup language as allowed by contents of the user profile records, 
documents at an end-user device, the documents being 20 21. The method of claim 20 wherein the locating linking 
stored for retrieval at one or more computer systems information further comprises finding all href attributes 
attached to a network and containing linking information associated with a found XLink element by 
representing resource addresses, the method comprising the if the XLink element has a simple type, finding all href 
steps of: attributes in the element start-tag, and 

entering user identification information, 2 5 if the XLink element has an extended type, finding all href 

authenticating entered user identification information and attributes in locator and document element children of 

loading user profile records associated with the authen- the XLink element. 

ticated user to the end-user device, the user profile 22. The method of claim 16 wherein the displaying a 

records relating to the user's restrictions to at least one browser sub-window further comprises: 

of access to network resources and use of browser 30 creating dynamically a homepage markup language docu- 

specific controls, merit which includes the linking information indicated 

displaying an application window at the end-user device to be allowed, and 

including application specific controls and data, displaying the homepage markup language document in 

wherein the application specific controls are responsive the browser sub-window so that the allowed displayed 

to the content of the user profile records and comprise 35 linking information can be accessed by the user, 

a browser control, and 23. The method of claim 16 wherein the browser specific 

displaying, within the application window and respon- controls further comprise a control the activation of which 

sively to user activation of the browser control, a causes display of a selection list presenting the linking 

browser sub-window including browser specific con- information indicated to be allowed for user selection and 

trols and markup language documents, wherein both to access. 

the displayed browser specific controls and linking 24 Tne method of claim 16 wherein the indication of 

information retained in the displayed markup language aUowed linkm f information indicates only whether or not 

documents are responsive to the content of the user ent £ e Ef^P [ an ^ documents are allowed, 

profile records method of claim 14 wherein user profile or user 

1C ,™ , ' c i ■ it u • »u u -a a* directory databases are resident on one or more network 

15. The method of claim 14 wherein the browser specific « „„j „,u„„- i„ a- ,u 

. , . ... ^cuc • . c attached computer systems, and wherein loadmg the user 

controls comprise a location entry field for user input of fl . „„ . ,l / „„■, „ ' .„• „ „ • ? , . 

,■ , • •„*■„„„„*•„ „^^™oo=o k„ profile records to the end-user device comprises download- 

hnking information representing resource addresses to be f C1 . ,, . r , , 

accessed, and wherein displaying not of the location entry oTX^ory!^! 

field in the browser sub-window is responsive to contents of 26 ^ me(hod rf ^ u ^ comp[ising; prior tQ 

^l^^aS^U^c^ottbc^r 50 J 6 p «* identmcation information, a step of 

~, , . , . . r „ , .. , . directing a browser program active in the end-user device to 

profile records comprise an indication of allowed linking „ , 6 . j „ , u - u i j- c 

^formation , and wherein delaying markup language docu l^L^ ST dlT £ 

rS^i^^iT^i^n 0 ^ 0 ^ subsequent steps of displaying an application window and 

linking information, whereby the user can access only 55 dis ^ a br F owser sl f b .window. 

allowed resources from displayed markup language docu- £ method rf ^ u ^ ^ profi , e 

me iij '-ru .u j c i • 1/: t. • n i- i • • c records relate to the user's restrictions to access to network 

17. The method of claim 16 wherein all linking informa- resQurces and ^ of brQwser spedfic ^ 

tlon vindicated as allowed ...... . 28. The method of claim 14, further comprising the steps 

18. The method of claim 16 wherein displaying markup j. > r © r 
language documents further comprises filtering markup lan- 60 , , 

guage documents before display to delete Unking informa- creating for each user but not by each user a user profile 

tion that is not indicated as allowed by contents of the user record, and 

profile records. preventing access by each user to his or her user profile 

19. The method of claim 18 wherein the markup language record so that each user cannot alter his or her user 
documents comprise HTML documents, and wherein the 65 profile record. 

filtering HTML markup language documents further com- 
prises: ***** 



